Bouke

ONLY if your TC is 23.976 or 29.97ND. Then you have a speed difference of 0.1 % meaning 3.6 seconds per hour. For 24, 25, 30, 50, 60 120 and drop frame rates there will be no noticeable difference. For time warping video, as mentioned a couple of times, that is VERY easy. A long take is close to never used in full, so it's very easy to cut out / slip a few frames when the angle is not used. An offset of 1 to 2 frames is often barely noticeable. (If you're in the back of a movie theater, the slow speed of sound makes that you're out of sync by 2 frames...) The main trouble is that it takes time, so a clap / flash at the end of the recording to check how many frames to add / loose would be handy.

Please, don't make this kind of stupid remarks

Well, I did some research years ago. A GPS receiver is dirt cheap, and coding for it is incredibly easy. (Just connect to it, and data comes in in human readable form.) But, the clocks from satellites do NOT run at the wall time on earth. They have an offset, that is increased every such time (I forgot...) So, to get the real time, you need to know the offset. But that is only broadcasted every hour or so. Then, it might take a long time for the unit to find a satellite, that is not nice for run & gun work.

Working on a set of tools: Tool to merge BWF files into one long poly or mono file. Tool to log mute moments Tool to extremely fast offload Zaxcom MARF cards (Copy only the 'new' data, instead of the full card.) the Merge tool does something like 'autosequence', but with patch. The mute tool is a simple util that works with the merge tool, it will mute specific moments of specific tracks in the timeline I could use some input on how to improve it. Background: Client is shooting real life soap (or alike) with a gazillion of Zaxcom transmitters that also record. They want to use the data from the transmitter rather than the wireless (RF faults etc.) And he does not want 'private' moments to go to Post, nor does he wants talent to mute their transmitters. If you like, toy with the stuff below. (And give feedback, either here or in PM) Test set.zip BWFmergeBeta.dmg MuteLogger.dmg Test set.zip

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!

(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.))

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..

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.

No clue how to accomplish that. Wine / WineBottler chokes on it. Yes, that won't be hard to make. No clue, the interface comes back with the settings as I've left them... 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...)

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.

Hmm, I can't find it...

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.

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.)

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

Thanks all. I have worked for political parties / persons that I truely HATE, but did my job cause it was in the line of democracy. (The party did not hire me, the governement, and every legal party gets it share.) I did my job, made a very decent clip out of it, even knowing what lying backstabbing bitch I was editing. Fun story, something like that once totally backfired when my counterpart at the governement (I'm independent) decided to make a 'bad' video: a stupid extreme right wing idiot got funded to make a video, he did the job and told the 'talent' the first take (and his delivered chroma key backdrop of a 60 pixel wide GIF was fine). End result was hilariously bad, but went viral on YouTube. (Sadly it is removed...) Long story short: I have told them (my contact at Scientology) I'm not taking the job.