< Back to IRCAM Forum

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


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

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.


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.

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.


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,