Bouke Posted August 7 Report Share Posted August 7 Can someone help me out with how the Zaxcom eco system works? From what I know, their stuff records to a 'propiatary' .zax file, that needs to be converted to BWF after offloading. Situation: Client shoots with 20+ Zax recorders (and no, I have no clue what kind of them, client is on vacation now, but I have time, so I want to be ahead.) My job is to autosequence them and put them into one giant 50 track / 24 hour+ BWF file. That's no issue, but converting all the inputs to BWF before I do my thing seems silly. I think .ZAX is plain PCM data, am I right? Can someone help me with some info on how things are stored? (Short testclips would be nice!) Thx Bouke Quote Link to comment Share on other sites More sharing options...
The Documentary Sound Guy Posted August 7 Report Share Posted August 7 The .ZAX files you mention are a proprietary pseudo-filesystem that Zaxcom calls MARF. The files don't correspond one-to-one with audio takes; instead the act more as data blocks that together make up a complete data partition. All of the .ZAX files are created and present when the card is first formatted; recording new takes modifies the files, but doesn't create any new ones. I don't think anyone has reverse-engineered the format yet, and I'd imagine it would be pretty labour intensive to do so. It's probably possible, but you won't save yourself any headaches compared to the conversion step. The mainline Zaxcom recorders (Nova, Deva, Nomad etc) all write MARF to the primary card, but will mirror ordinary .BWF files to the mirror card, formatted FAT32. So, the normal workflow is to hand in the mirror card at the end of the day. If your client is shooting 20+ recorders, that probably means he's recording on 20+ transmitters in addition to (or instead of) a main recorder. You are correct that the recorders in the transmitters exclusively record using the MARF filesystem, which means they can't be straightforwardly copied as files. Doing the conversion to BWF via Zaxconvert is the only viable option short of coding something yourself. There is a command-line version of Zaxconvert that could be used to automate transfers via scripting; I've been thinking of writing a script to do that myself. If you are looking to save some labour, this is where I would start. As for how data is stored within .ZAX files, my *guess* is that the main recorders probably store PCM data, but I suspect the transmitters store the raw digital modulation data that they transmit, which is then translated into PCM by Zaxconvert. This guess is based on the fact that record capacity changes depending on what modulation the transmitter is in; ZHD96 produces less data than XR or "standard" mono or stereo modulations. In addition to the PCM data, you would also need to reverse-engineer the file index and metadata structures. Long story short, it may seem silly, but there's no getting around the conversion step to BWF before you can use the audio normally. Quote Link to comment Share on other sites More sharing options...
glenn Posted August 7 Report Share Posted August 7 You can either convert the cards one at a time or Viviana has a multi card converter that I think can do 4 cards at a time speeding up the process. Either way the audio on the cards will need to be converted. This can be done in post as the files are loaded into the edit system. Glenn Quote Link to comment Share on other sites More sharing options...
Bouke Posted August 8 Author Report Share Posted August 8 Ok, thanks! The command line util sounds promising, can it be used to offload cards? If so, I can do the scripting. (Well, write a Python GUI for it, that takes multiple cards.) But on the other hand, if Ambient already has done this, why? (They're friends, and it's an unwritten law not to fish in another one's pond.) Quote Link to comment Share on other sites More sharing options...
The Documentary Sound Guy Posted August 8 Report Share Posted August 8 Yes, that's exactly what the command line utility does. I went looking for the Viviana (Ambient?) box ... all I was able to find was their Viviana Cloud box, which allegedly can read Zaxcom cards. But, I didn't see a multi-card capability, it costs $400, and it (only?) offloads to the cloud. I was able to find a generic multi-card reader for about $100, and Zaxconvert is free and scriptable. So it seems cheaper and more flexible to me. Quote Link to comment Share on other sites More sharing options...
Bouke Posted August 9 Author Report Share Posted August 9 Ok, In that case, can you send me a (small) disk image with some clips? Or does the command line util not work from a 'normal' disk (with the Marf stuff)? In that case, I need to find a local guy that can send me a card. Quote Link to comment Share on other sites More sharing options...
Bouke Posted August 9 Author Report Share Posted August 9 On 8/7/2023 at 10:20 PM, The Documentary Sound Guy said: There is a command-line version of Zaxconvert Hmm, I can't find it... Quote Link to comment Share on other sites More sharing options...
The Documentary Sound Guy Posted August 9 Report Share Posted August 9 Yeah, they don't make it easy to find, but they maintain a Google Drive with all their more recent software. What you're looking for is in here: https://drive.google.com/drive/folders/13iBT16j-KUiR5sp31ywfJbZQZHhPG9nC The most recent version is 6.57, which is the one in the independent ZaxFile folder. Quote Link to comment Share on other sites More sharing options...
The Documentary Sound Guy Posted August 10 Report Share Posted August 10 Here's a sample MARF formatted partiton with a test recording for you to work with. Warning: The zip file may be small, but it expands to a 4GB card size when extracted. 4GB is the smallest card I have. ZAX test partition.zip Quote Link to comment Share on other sites More sharing options...
Bouke Posted August 11 Author Report Share Posted August 11 Thanks. (Zipping zeros is always fun : - ) Looks simple enough, but yes, no fun reverse engineering. And no 'real' need, ZaxConvert GUI accepts multiple inputs, cards need to be offloaded anyways for backup. The command line util is simple enough for me to write an gui, but why would it be better than the Zac gui itself? It cannot send data to StdOut or alike for me to process further... So what's there to automate further? And, it's Win only, while I think most people here are on Mac. Quote Link to comment Share on other sites More sharing options...
The Documentary Sound Guy Posted August 11 Report Share Posted August 11 I'm the black sheep on Linux, so I can vouch for the fact that it works with Wine ... which should also allow it to work (unofficially) on Mac. I think there's some fairly simple automation that could be done: Auto-trigger a transfer as soon as a card is inserted, support for multiple simultaneous (or properly queued) transfers when multiple cards are mounted, auto-unmount after a transfer is complete. Also, I think you overestimate how advanced the Zaxcom GUI is ... the lack of persistent (and sane) default options is a regular frustration to me. That said, the GUI is clearly the first-class citizen here; it's more capable and flexible than the command line util, and there are things that can only be done in the GUI where the CLI lacks options. For post-processing, it's true that it won't sent data to StdOut, but I can envision automatic processing of newly-transferred files as soon as it finishes writing (potentially even before the full card has transferred, though that's probably a bit ambitious for a simple script and the labour involved). I also envision some command-line streamlining of the sound reports, since the default data in the reports generated by the GUI are a bit sub-par (notably, it includes columns for 24 tracks, regardless of how many the source recorder is capable of, or how many were enabled). Reports could also be merged, or production metadata added. Quote Link to comment Share on other sites More sharing options...
Bouke Posted August 11 Author Report Share Posted August 11 6 hours ago, The Documentary Sound Guy said: I also envision some command-line streamlining of the sound reports 5 hours ago, The Documentary Sound Guy said: which should also allow it to work (unofficially) on Mac. No clue how to accomplish that. Wine / WineBottler chokes on it. 5 hours ago, The Documentary Sound Guy said: I think there's some fairly simple automation that could be done: Auto-trigger a transfer as soon as a card is inserted, support for multiple simultaneous (or properly queued) transfers when multiple cards are mounted, auto-unmount after a transfer is complete. Yes, that won't be hard to make. 6 hours ago, The Documentary Sound Guy said: the lack of persistent (and sane) default options is a regular frustration to me. No clue, the interface comes back with the settings as I've left them... 6 hours ago, The Documentary Sound Guy said: I also envision some command-line streamlining of the sound reports Those are simple CSV files, not hard to work on from Python, but I have no clue who uses them for what. (I'm a coder, used to be an editor, but never had to work with sound reports...) But, can we motivate Zaxcom to update the CLI version, and port it to Mac? (64 bits of course...) Quote Link to comment Share on other sites More sharing options...
The Documentary Sound Guy Posted August 11 Report Share Posted August 11 2 hours ago, Bouke said: But, can we motivate Zaxcom to update the CLI version, and port it to Mac? (64 bits of course...) No idea, but Glenn who commented above is from Zaxcom, so hopefully the seed is planted. 2 hours ago, Bouke said: No clue how to accomplish that. Wine / WineBottler chokes on it. I can't tell what error you are getting, but it should be possibles. The gotchas I'm aware of all relate to quirks of the command line. Try: - capitalization (OSX command line may be case sensitive - locate the input using Z:\ , which is mapped to / - file paths passed to ZaxFile.exe should use backslashes, escaped or enclosed in quotes So, and example of a working command line (for me) is: wine ZaxFile\ 6.57.exe Z:\\Volumes\\ZAX_SD_CARD\\Folder\ Name Works with wine 5.0-3ubuntu1 (which is wine 5.0 packaged for Ubuntu). That's not a super recent version, so I would think whatever version you tried would be working, but if not, you can seek out 5.0. Good luck if you decide to stick with it... Quote Link to comment Share on other sites More sharing options...
Bouke Posted August 13 Author Report Share Posted August 13 On 8/7/2023 at 10:20 PM, The Documentary Sound Guy said: but I suspect the transmitters store the raw digital modulation data that they transmit, which is then translated into PCM by Zaxconvert. Definitely something like that. I took your sample file, deleted the empty .zax files, trimmed the non empty (removing all trailing zeros), and ended up with a 344 KB file, that was still fully functional. This 344 KB became 2,4 MB when converted to BWF. That's 7 times bigger. So 'some' data compression is applied... (No clue if it's destructive or not, but I don't care, as long as it sounds good : -) But, this knowledge makes that I could create something that could backup cards fast, and save storage. (But that's only good as backup 'in case of emergency', as the MARF stuff can't be played / used. However, ZaxConvert is able to create BWF's if needed.) I don't think it will be significant faster than using the ZaxConvert, unless you offload to a very slow disk. (I guess the disk to oflload to is WAY faster than the cards.) I'm not going to pursue the Wine option, too much hassle. (I get a 'wrong CPU type' error.) More later. Quote Link to comment Share on other sites More sharing options...
The Documentary Sound Guy Posted August 13 Report Share Posted August 13 Oh, wrong CPU type makes sense. I assume you're on an M1 ... that's something that Wine won't fix. When you say your file was still fully functional, you mean you ended up with a .Zax that could be converted in ZaxConvert? Did you lose any metadata? Quote Link to comment Share on other sites More sharing options...
Bouke Posted August 13 Author Report Share Posted August 13 Nope, I'm on a fairly old Intel I5... But, for the stuff I do and the support I can give given the money, I don't want to have too much hassle... For the trimmed stuff, see the attachment. No clue what metadata there is to loose, as there is hardly any. (And I think the metadata is not in the .zax files, but in the .zzz file.) LAV__YEL.zip This should unzip to just a small .zax file, and a .zzz file, that 'should' work fine in ZaxConvert, give you the same as the 4 gigs you've posted.. Quote Link to comment Share on other sites More sharing options...
Bouke Posted August 13 Author Report Share Posted August 13 (my guess is that the Zax stuff is not so sophisticated, it just allocates space so no other app can interferere with it, Nothing wrong with that, but easy to parse. What I've done is not even remotely hacking, it's just extracting data, to feed ZaxConvert to it's expectations (for as far as I know, I just have one channel on one clip of one recorder, but I bet a box of beer this will work in any case.)) Quote Link to comment Share on other sites More sharing options...
The Documentary Sound Guy Posted August 15 Report Share Posted August 15 I'm away for a week, so can't verify much. My main curiosity is to confirm that it still opens in Zaxconvert, which you said it does. The metadata I was mainly concerned about was timecode. Also, the transmitter name can be changed remotely, so can be used to identify who was wearing it at any given time. In the sound report, the track name inherits the Tx name, which can be handy. I have no idea why Wine isn't working for you then ... but since you've already decided to stick with the Native Mac GUI, I guess it's academic. For reference, the original reason for pre-allocating everything was to work around having broken files in the event of power loss (i.e. the battery runs out). This engineering hack dates from the '90s or early 2000's ... I'm not sure if it was ever a great solution, but they've stuck with it. A modern solution would be to use a journaled file system and disable write-caching ... but for whatever reason they still advertise it as a feature. Personally, I wish they'd just move to modern tech. Quote Link to comment Share on other sites More sharing options...
Bouke Posted August 15 Author Report Share Posted August 15 16 hours ago, The Documentary Sound Guy said: My main curiosity is to confirm that it still opens in Zaxconvert, which you said it does. Here is proof of concept: ZaxTrimBeta.dmg This is Mac only for now, but I can make it Win also. (And Unix, but that will take a bit longer...) It wil copy MARF / Zax 'trimmed', so as small as needed. ZaxConvert 'should' still be able to work on the smaller / trimmed files. Fair warning, it WILL overwrite existing files, so choose your output wisely! Quote Link to comment Share on other sites More sharing options...
.png.279748a58a2b862b7aa5f3b84126e232.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.