< Back to IRCAM Forum

MUBU container problem for reading a multi-stream SDIF file into multiple tracks

MuBu
#1

Hello,

I’m facing a problem with the MUBU reading command of a multi-stream SDIF file.
Here is my use case : I have two tracks that record the data of a wiimote (pitch/roll/yaw) and a wiiboard (x/y) in a synchronous way. The respective MUBU tracks are predefined with the following SDIF informations :
1/ track wiimote info SDIF.StreamId 1 SDIF.FrameSignature XWII SDIF.MatrixSignature XWMT SDIF.MatrixName WiimotePRY
2/ track wiiboard info SDIF.StreamId 2 SDIF.FrameSignature XWII SDIF.MatrixSignature XWBD SDIF.MatrixName WiiboardXY

To write these 2 tracks into an SDIF file named « toto », I use the MUBU command : « write toto.sdif ».
To read the 2 streams from the SDIF file into each corresponding track, I sequentially use 2 MUBU commands :
1/ « readtrack wiimote toto.sdif »
2/ « readtrack wiiboard toto.sdif »
Here is the problem : only the wiiboard data (second stream of the file) are read into both predefined wiimote and wiiboard MUBU tracks.
It looks as if the « readtrack » command couldn’t associate an SDIF stream to the corresponding MUBU track, whereas these associations have been provided when writing the tracks…

Any suggestion about this problem ?

N.B 1 : The combination of commands write/readtrack works fine if I define a single track associated to a unique SDIF stream (i.e. when writing/reading either wiimote or wiiboard data only)
N.B 2 : A combination of symmetrical commands writrack/readtrack for each track doesn’t solve the problem

#2

Hi jojo,

indeed, how should the sdif files know from which track they were written? This is only given when you write in the native .mubu format (which is sdif+some conventions).

As documented in mubu help, using readtrack, you need to select the stream id you want by @selection #1 or #2. However, using read, streams should be split into tracks automatically.

Best!

#3

Hi Diemo,

Thanks you for your answer.
Ok I understand better now why my SDIF streams couldn’t be read correctly in the MUBU tracks.
So I tried 3 solutions according to your advices :

1/ Executing sequentially these 2 commands :
« readtrack wiimote toto.sdif @selection #1 »
« readtrack wiiboard toto.sdif @selection #2 »
I’ve here a problem to type these commands in a message box, because I work in an abstraction, and Max/MSP doesn’t permit me to lock the patch without replacing the pounds #1 or #2 by 0… Is it possible to bypass this behavior ?

2/ Executing the « read » command directly :
I already tested this solution, but it didn’t fulfill my need.
Actually the data are correctly loaded from the 2 file streams, but in 2 additional tracks.
It doesn’t seem possible to rewrite my existing tracks, because they are declared as predefined in MUBU.
That’s the reason why I used « readtrack » commands instead of « read ».

3/ Write in the native .mubu format :
This seems to be the magic solution, nice :slight_smile:
When I execute the « read » command, all the data are correctly read and formatted in my predefined tracks (so with predefined multiple tracks, « read » works fine from .mubu files but not from .sdif files).
The only thing that is not restored relates to the SDIF informations I provided in the tracks before writing them.
Any suggestion to enable that ?

Last point : If I adopt the .mubu extension to save my data files, will it stay possible to read these files in other SDIF software editor ? (I’ve planned to test the pysdif library for example)

Thanks again for your help.
Jocelyn

#4

Hi Jocelyn,

Ah, try to compose the message with sprintf. We should accept \# or something.

That might be because the name is generated from the found SDIF. Try to start with the tracks named as they will be loaded from sdif (you can give a prefix). If that fails, you could rename the tracks (maybe remove the existing ones).

It should be. This might be an oversight from us.

Sure, but with non-informative sdif types, however all mubu track information will be in the NVT.
This kind of defeats the purpose of SDIF as a self-describing interchange format, so the solution as proper SDIF is cleaner.

Best

#5

Ok nice,
With the composition by sprintf message, I get the expected behavior.
And I can thus save/read my data files in the standard SDIF format.
Very helpful, thanks Diemo,
Jocelyn