< Back to IRCAM Forum

Pm2 analysis -> SDIF with 1TRC matrices

Pm2
#1

Hello pm2 community —

I’m having trouble calling pm2 at the command line and referencing precise SDIF output file specifications, trying to simulate how AddAn once produced a harmonic partial tracking analysis that output 1TRC frames to an SDIF file.

In short, how can I reproduce 1TRC frame output in AudioSculpt while running a similar harmonic partial tracking analysis (in which an f0 temp file is referenced by pm2 to generate the partials, like AddAn)? AS insists on writing HRM frames with its pm2 data, but I see no way to specify an alternative in the shell. I’d like to keep using AddAn but there are continual problems that make it unfeasible.

Having examined the output of my old AddAn files (via SDIFtoText droplets included with AS), I can tell that AddAn was writing 1TRC frames. These files read seamlessly into CNMAT’s SDIF-buffer, SDIF-tuples, threefates, etc., for resynthesis in Max.

AS only produces 1TRC frames when the analysis is “inharmonic,” but for my purposes I need a harmonic analysis. AS’s harmonic analysis only seems to allow HRM, and these don’t seem to read into the CNMAT SDIF tools for resynth, regardless of stream number, etc.

Besides writing a path to the output SDIF file, I see no way to specify the SDIF frame or matrix type in a pm2 call at the command prompt. AddAn only wrote this output path as well; no specifics about SDIF, and the frames were always 1TRC.

Here is the command AddAn would run, captured in the SDIF file:

pm2 -v -Apar -P[path] -S[path] -R48000.0 -Wblackman -N2048 -M1920 -I480.0 -a0.01 -r0.01 -c0.5 [path to output file]

This produced 1NVT with 1TRC frames. The same command in AS produces a file with HRM.

Does the application (AS or AddAn) somehow determine specifications for the SDIF output file apart from the pm2 call that runs the analysis?

I’m not sure exactly what determines this behavior, but it seems closely related to pm2 and I don’t see a specific SDIF thread on the forum where I could share these questions.

Thanks in advance for any guidance on how to resolve this!

All my best —
Louis

#2

If you run the pm2 command line (using the pm2 executable from AS, AddAn, or command line tools), the output will contain 1HRM frames.
Unfortunately I didn’t manage to make AddAn work to check this, but from the source code it seems that AddAn then modifies the file to change the frame and matrix type to 1TRC, leaving the rest alone, with this command:
sdif_signature_convert [path] 1TRC
This executable is in the Kernels subdirectory of the diphone application, and is of course very old and 32-bit, but changing the types is all it does, so that should be doable another way

The difference between both types is the interpretation of the first column: in 1HRM these are harmonic numbers identifying a partial, whereas in 1TRC these are arbitrary track IDs.
The main risk I can think of in changing the type like AddAn does is that a given ID could be in one frame, not be present in the next, then appear again, something which would not happen with a track ID. Such a gap could be an issue for code reading the file.

1 Like
#3

I don’t know anything about Max, but I looked at the code of the CNMAT externals, and I didn’t see any reference to 1TRC, so I don’t know why the 1HRM data doesn’t load. But it seems SDIF-tuples accepts a “matrix” message to specify a matrix type (the default is the same as the frame type). A wild guess, but could there be such a message with 1TRC somewhere in the patch?

#4

Thanks as always Fred! I’ll take a closer look and see if I can alter the behavior of the CNMAT externals, and I can potentially get in touch with someone there for help with their externals as well.

I really appreciate you checking the source code!

As for this sdif_signature_convert command, is that something I can run in the shell? I don’t see that documented in the pm2 command line help.

#5

Wow, I don’t even know where this sdif_signature_convert comes from, no wonder it’s not documented, I just found that call in AddAn code I can’t even compile. This is all ancient code, I’m not even sure the version I found is the right one. I don’t think you even need it. But yes, you can run it from shell. It looks like a hack though
I don’t see why the 1HRM don’t load (maybe the github code doesn’t match your externals). If the on/off/on (forgive the Mission of Burma reference) is an issue, we have a converter we could make available. But that would be occasional glitches, not failure to load

1 Like
#6

Mission of Burma! I love it…

Thanks so much for checking sdif_signature_convert. It won’t compile? Wow that’s something. What do you mean about the matching Github code, by the way? Code for CNMAT externals? I’m running their latest release.

The main barrier is the SDIF-tuples object, which is giving me the errors. Maybe there’s a feature that’s undocumented. I might look for an alternative using MuBu, but then it becomes a question of whether or not the threefates object will manage the birth & death of partials in an HRM matrix as it does for partial tracks. (If anyone else reading has insight on this, please share!)

For now my hack-y solution is to export HRM from AudioSculpt, SDIFtoText, then in a text editor replace-all HRM with 1TRC, TextToSDIF, and then finally it loads (sometimes) in the CNMAT objects. I guess this is basically what sdif_signature_convert is doing.

Have a great weekend Fred! —