Jump to content

new app to add / change timestamp on el cheapo recorders


Bouke

Recommended Posts

Hi guys,
A soundguy doing sports with lots of small recorders asked me to promote files from small, non-tc capable recorders to BWF.
So, I've made him something that does this, and also can include a custom offset.
So, you can set the actual TC 'somewhere' in one of the files (it has a player build in), and all the files will get the 'correct' timestamp based on a bit of math on their file creation time.

(Of course this is only second accurate for the other files, as the creation time is not more accurate than that.)

Now my questions:

-What more should I add to make it practical for daily use? (metadata / sound report or is this overkill?)
-Since there is a bug in 'some' versions of OSX that replaces the file creation time, do you guys have a SOP for offloading cards? Or should I add it?

-Should I add compensation for drifting clocks? I know for sure that internal clocks will drift, but I don't know if this is a fairly stable drift. If the latter, it's easy to calculate that and compensate for it. That could make it a bit more accurate.

-Do the cards in these recorders have 'some' form of ID what recorder it was that used them? (I can imagine that being practical to identify the files later on.)

 

Other ideas?

 

If you want to toy with it as it is now (fully functional but not all bells and whistles that are possible), drop me a line.

 

Bouke

 

 

Link to comment
Share on other sites

Hi Bouke,

This is quite timely for me as I have a show going out in 3 months that'll be deploying a large quantity of Zoom H3-VR ambisonics recorders (among other things). These do actually write timestamped BWAVs, though the timestamping is from their domestic-quality RTC so not really production / post friendly. Plan A is to pair each one with a Timecode Systems Blue, which Zoom is allegedly going to support in a 'future firmware update' that may or may not happen in time.

 

I'm guessing with your new app, we could go around each recorder with a TC Slate (or even better, Movieslate app, that can create a clap time log) and give each Zoom a clap shortly after pressing record on each one, then the data wranglers can go in after upload with your app, find the clap,  and enter the matching real production TOD TC from that log? That sounds as accurate and labour-efficient as any other plan I have. It may actually be more robust than the TCS Blue idea. I'm guessing it will work fine with 4-channel Poly BWFs as input?

 

Now to your questions...

 

- Sound report: not a big deal for me, as I'd be handling that along with the other recorders another way. Ability to add Metadata (specifically track names that would show up in Pro Tools as channel names) might be useful. In the case of the H3-VR, it will split files when they exceed 4GB, supposedly without dropping samples, so it might be useful to be able to tell the App to stamp consecutive files with the next TC frame from the calculated end of the last file rather than the next full second when you know this is the case.

 

- We'd be using Hedge to upload, which deals with maintaining timestamps, but for all these cards, if your App had a built-in uploader that would be more efficient. What I'd not want is for the app to be modifying the original file on the micro-SD card in any way, we'd always be running it on an uploaded copy to make the delivery file.

 

- Timecode drift will of course happen due to slight differences in the clock rate between the recorders and cameras, and is usually a steady drift unless the cheap device is experiencing large temperature variations. The only way to compensate for this is to run a non-pitch-shifting time compression/expansion DSP process. You would of course need access to the 'reference' clock or file to know the amount of correction to apply. There is now a quite effective DAW plug-in for this (Auto Align Post) assuming you have matching reference audio from a camera or TC recorder. This can even deal with a fluctuating drift as it's really meant for aligning a Lav and a Boom track where the talent is moving in relation to the boom.

 

- Recorder IDs.. Im pretty sure most of the current handy recorders that natively create BWFs will stamp a device name (shows up as 'Originator' in WaveAgent), but I suspect if you have more than one of the same model, they'd appear the same. All the Zoom recorders can have a custom filename with user-defined text followed by a sequential 'take' number we use to tell them apart.

 

I'd certainly like to have a look at what you have already.

 

Cheers, nick

Link to comment
Share on other sites

My votes:  Report: yes.   Drift comp: I don't see how you can calc this, since the drift is partly caused by environmental factors in recorders without TXCOs.  Recorder ID: yes.  I would consider using the app for downloading instead of "finder copy/drag+drop".  Metadata editing: yes, for sure.  TC starts, scene+take+notes entry.

 

thanks!

Link to comment
Share on other sites

Ok.
For the drift, what I would need is a (manual) correct TC for one file, and another (manual) correct for a later file. The further apart the better. (At least an hour, more is better.)

This way I can do the math if the clock is slow or fast, and compensate based on that. But it will not compensate for temperature drifts, it will be just a bit of an improvement. (My old mac clock was 4 seconds slow over 24 hours, that is a lot...)

 

Now, if the files are already BWF, they are stamped as a accurate as the clock in the device is I presume.

You can use that as well to set the correct timestamp, and the math on other files can be done on the offset of the BWF timestamps rather than the creation time.

If a file is split due to the 2 (or 4) gig limit, it won't be a problem since all get the same offset and all should be well.

 

@nick, you can also walk around with your master TC device, insert that and record a few seconds or so on the cheap device, switch back to mics and  then have my LTCreader to 'work on wave', and let it rip away. It can do the same thing, reading the LTC and setting the guessed values on all other files from that folder.

 

For offloading and metadata, i'll build it in tomorrow and send you test versions.

 

 

 

Link to comment
Share on other sites

Bouke wrote: @nick, you can also walk around with your master TC device, insert that and record a few seconds or so on the cheap device, switch back to mics and  then have my LTCreader to 'work on wave', and let it rip away. It can do the same thing, reading the LTC and setting the guessed values on all other files from that folder.

 

I thought of that, but unfortunately the Zoom H3-VRs don't have an external input - only the onboard ambisonic mic array. I actually tried feeding TC into a small speaker and holding it close to the mics, but neither your LTC Reader (demo) nor the Tentacle software could decode it.

Link to comment
Share on other sites

33 minutes ago, nickreich said:

Bouke wrote: @nick, you can also walk around with your master TC device, insert that and record a few seconds or so on the cheap device, switch back to mics and  then have my LTCreader to 'work on wave', and let it rip away. It can do the same thing, reading the LTC and setting the guessed values on all other files from that folder.

 

I thought of that, but unfortunately the Zoom H3-VRs don't have an external input - only the onboard ambisonic mic array. I actually tried feeding TC into a small speaker and holding it close to the mics, but neither your LTC Reader (demo) nor the Tentacle software could decode it.

That was a GREAT "Hail Mary", though!

Link to comment
Share on other sites

I rarely work with such recorders, but when I do I really really don’t like entering any form of Metadata on the recorder, so for me it would be a cool option if your program could 

 

- let me enter the channel names of one track and then it will automatically do that on the other tracks (as an option)

 

- allow me to either rename one file and then automatically renames all other tracks the same but adding a suffix or alternatively add a custom pre- or suffix to every takename. 

 

Since most will use these recorders in a „press record once and let it roll all day“ scenario (or so I assume), these would be luxury feature and are non-essential

Link to comment
Share on other sites

On 1/23/2019 at 2:38 PM, Bouke said:

Hi Constantin,
Please elaborate on the file names.

Metadata can hold a name as well, not sure who uses that.
(I personally hate it when a filename in my bin does not match the filename on disk on most scenarios)

 

 

 

Hi Bouke, what I meant was that I could edit the filename itself. Not necessarily in the metadata. Although there could be an option (like on SD's WaveAgent) to rename the file following the name field in the metadata. Recorders will often name files according to their own convention, like 33528-20192401_001. The 001 part being the takename. It'd be useful if I could rename the first file as for example: Sc23-car_001. The program would rename all following files like that, but keep the take counter. 

(thanks for the trial, I hope I'll find some time in the next few days to try it out).

Link to comment
Share on other sites

  • 4 weeks later...

Ok, the app is public now.

You can find it here

It does all that is promised, and a bit more.

Aimed at you having to do as little work as possible, but I can imagine it will be a HUGE timesaver in post.

 

Now, I've done my best (to my horror I now see i've been working a month on it.) to accommodate all needs, but I'm an editor and coder, not a sound guy.
So, there probably are more improvements to make. Don't by shy with comments!

 

Oh, fair warning:

If you run the demo:
Offloading will do no harm to your files.
Altering the metadata / setting timestamps WILL! (It will add 2 seconds of silence every 25 seconds.)

 

Screen Shot 2019-02-17 at 15.42.14.png

Screen Shot 2019-02-17 at 15.40.14.png

Link to comment
Share on other sites

Thank you!

But, did you already had any hands-on experience with it?

(The proof is in the pudding, and I did a lot of toying around of course, but I work under lab circumstances.)

 

I do like the drift compensation, but I'm still not sure how that is going to work out in the real world.
(It will work for sure on the clip you set it, but will the drift percentage be app. the same on other days?)

 

 

Link to comment
Share on other sites

Hi Bouke, Trying it out as we speak, great job. I am playing around with some old zoom H4 material I have laying around. A point of critique; If you ask me I would stay with the "official" GIU guidelines for the respective platform, in my case OSX, but obviously the WinTel guidelines for that platform. I had a bit of mental adjustment needed to comprehend your choice. It is a minor detail, but worthwhile IMHO. That's why I like the Tentacle Sync software so much, native, easy to understand for beginners, a known environment. 

 

Link to comment
Share on other sites

Hi Vincent,

12 hours ago, Vincent R. said:

old zoom H4

IIRC, those files have a BWF timestamp, but all set to 0. (Btw, why is SD using sample 1 as 'since midnight', as the beginning should be 0 IMHO?)

Should make for nice testing material.

 

12 hours ago, Vincent R. said:

I would stay with the "official" GIU guidelines

I would if i could, but my coding environment does not let me do this. I have to write my own interface. (Meaning, the button I use has 135 lines of code just to make them behave the way they do, and that is just to call an action. It sucks, but it is the way it is.)

So I also cut corners, especially if it is in projects like this (That will earn me close to nothing, I expect to sell 10 copies over the next years.)

The pulldowns are an example, those are easy to code since I have third party code to generate them for me.

Trust me, 80 % of the work is in the interface / making it 'look' logical.
Nevertheless:

12 hours ago, Vincent R. said:

easy to understand for beginners

I don't care. Like PT is 'easy to understand'.
My work is not for beginners. I totally agree that an interface should be as easy as possible, but trust me, it is very hard to make it so.
Every user wants something else, and every user wants it simple. I have made stuff where an end user could set the entire interface to it's liking, but then it's 'too complicated'.  (I can rant about this problem all day.)
So I try to give my apps a name that describes what it does, and give buttons a name that describe what they do. Then I try to follow other conventions. (Like JKL, but then I add the 'U' key for 'play a bit', that was stolen from M100, where it was the arrow up key. That one is not to be found on laptops, and the 'U' key is at a logical place for right handed people when they use the function in a normal fashion.)

 

Now, the original question was simple and logical. Set timestamp from recording time as BWF timestamp, as the stupid recorder does not do that itself.

Made totally sense and was easy.

Except that setting an offset was also logical, as setting the clock from the recorder right does not happen always.

and, while I'm at it, offloading cards, as that had to be done always, why use two apps if it can be done in one?

and, while I'm at it, why not add metadata like Track names?

and, while I'm at adding metadata, why not add the whole shebang, since it is possible and easy?

and, since the device WILL run at another speed, and (as Constantin wisely noted), the darn things will run the whole day, why not build something in to compensate for that?

Then it needs to be as versatile as possible, and all recorders have different ways of file naming / storing in folders / record mono, poly or combos.

Of course it needs to be able to run batches, where all clips get the same treatment. Except those who need another... (Orwell comes to mind :-)

 

So now we have something that once was very simple, but became quite complicated very fast, all due to 'logic'.

Get the point?

(Like if there are two standards. Someone says, 'that's impractical, let's make something that is universal'. Then we have three standards.)

You are all very lucky with the acquisition Wave 'standard' (That isn't as simple as you think, having mono/poly, the lack of acceptation of RF64 makes it ancient/outdated, let alone the lack of fader info.)

 

ok, /rant

 

11 hours ago, Philip Perkins said:

How soon will we be able to buy the legit version?

 

When you all say it is ready for rock 'n roll, and I come up with a fair price.

 

Oh, to make it worse, a few months ago I was ranting about clapperboards being obsolete, now I've found myself writing code to find a clap in a sound file, because it was the 'logical' thing to do...

I really must find a Vulcan monastery...

Link to comment
Share on other sites

@Bouke "easy to understand for beginners" was regarding the GUI, I understand the "if i would i could" explanation, You are using Java? The "mouse over hand" looks like the old one Flash/Shockwave was using in the projector/stand alone apps. As a former programmer myself I understand the constant struggle between usability/versatility all to well... I actually started building something similar as your app a while ago but as most programming projects of mine it stranded somewhere...

Link to comment
Share on other sites

Just now, Bouke said:

yes 🙂

(and no, but I'm still using Director, that can do more than you think.)

 

Ah (Macromedia) Director! jeez... forgot about that one, last time I touched that was in 1998 I believe. used it to make CD-roms, or even CD-i's for museums and such places.

  

Link to comment
Share on other sites

  • 1 year later...
  • 4 months later...
On 2/21/2019 at 7:00 PM, Bouke said:

I would if i could, but my coding environment does not let me do this. I have to write my own interface. (Meaning, the button I use has 135 lines of code just to make them behave the way they do, and that is just to call an action. It sucks, but it is the way it is.)

What coding environment are you using?(Adobe Director??)

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...