Boom Recorder Workflow Question

[ptalsky]

Hi all,

Just came off a project where I was recording up to 8 tracks on Boom Recorder and ran into a situation that I was sure about the best way to handle it.  Some setups I had all 8 mics running, other times I only had 3-4 mics running.  In these situations, do you reduce the number of tracks in Boom Recorder, or do you just continue to record 8 tracks, with most being blank?  I opted for the blank tracks, because all they do is take up room on the DVD, and don't seem to hurt anything.  To ensure post knew they were supposed to be blank, I labeled them all as "null", but wasn't sure if this was really the best way to go.

How do all you multi-trackers out there handle this?

Thanks!

Phil

[Richard Lightstone, CAS]

I maintain the same track count all the time on both BoomRecorder and the Deva 5  - which is 8 total tracks.  I know there are some who disable tracks they are not recording to save disc space and speed up mirroring.

My method is to record 8 tracks wether there is any source or not. First for simplicity and secondly so I don't have to consciously enable an additional track when needed in the "heat of battle".

I instruct telecine to transfer Ch 1 and 2 ONLY for dailies, so your concern of wether to note a track "null" is probably only helpful to the Post-Sound Editors who should be using all your recorded tracks.

Best regards,

Richard

[cmgoodin]

Were you recording Poly files?   If you were, I would suggest not recording blank tracks.  While it may take a little more attention in post to determine who is on what track, it speeds things up by a factor of 2 for every non real-time transfer of sound to a new media.  People casually say, Hey disks are cheap or Hard drives are big now and have plenty of room.  We forget that while it takes us the same amount of time to record a 10 minute  8 track file as it does to record a 10 minute 4 track file, the cost down the line is not taken into account.  Those 4 blank tracks have to be dragged along throughout the rest of the entire post chain.  It takes longer to copy them from disk to disk and they double the storage space.

Remember even if you are only using a small 1 second chunk from one track of that 10 minute 8 track file in the final cut, in many non-linear edit systems they have to drag the entire file (all 10 minutes and all 8 tracks) through every post process.  This is to allow for the flexibility to change the edit at any point down the line.  So those blank tracks do have a large impact on work-flow but few take it into consideration.

---Courtney

[Jeff Wexler]

My method is to record 8 tracks wether there is any source or not. First for simplicity and secondly so I don't have to consciously enable an additional track when needed in the "heat of battle".

Best regards,

Richard

I think we should all pay attention to Courtney's points above, especially as they relate to POLY files. It is true that many of the systems in use in the world of non-linear editing, do act in a non-destructive way, so that as Courtney describes, even a 2 second piece of one track (which is part of a 10 minute, 8 track poly file) will be present in the edit system. In fairness to Richard's method of 8 tracks all the time, I believe that having telecine only transfer Track 1, even with a polyfile and multiple tracks recorded, means that the picture editor will have ONLY 1 track available --- thus, there will be only 1 track that is carried through during the picture editorial. If your polyfile is brought into the editorial station complete, and the editor chooses only to use track 1, it is true that the 8 track polyfile will have to be carried along all the way through the edit.

Personally, and since I do not record a lot of tracks, I always arm and disarm only the tracks that are needed, and have only recorded blank tracks those few times we have had the ODD TRACK COUNT problem with older Avids (and when my disks were going straight into that older Avid).

Regards,  Jeff Wexler

[Ramsay]

I only record the tracks I need and always poly. No complaints from Post and lots of space saved on my HD, also less strain on the system (but I don't know if it really matters). I also like Post to know from the start that whatever track count shows up, each track is always 'loaded' with something so there is no "I wonder if there is something on this track?" questions. I was worried that through the course of a complicated scene the characters mics. sometime show up on differerent tracks depending on who I am recording but there have been no issues so far. The note field always shows who's on what track for easy reference. Track 1 is always the mono mix.

[tourtelot]

And I split the difference.  I always keep four tracks armed and assign more tracks for more complicated setups.  Leaving the four tracks armed seems to keep me from iso'ing a mic and then, because sometimes I forget, not recording it (most times!<g>).  My primary recorder, a DV824, sets up with Tk.1 being my dailies mix with Tr.2 sent to telecine as "next best dailies."  Perhaps playback music, dedicated ambi, second boom iso, or deep-BG RF mic.  The next six tracks are for iso'd RF typically.  Seems to work out okay and I was told by the picture editor on my last series that he gets all the tracks in his Avid loads and will actually cut in isos if it makes the network copies better.  Re-recording happens much later, and I was grateful for the care that he took to make the episodes sound better for the network.

D.

[ptalsky]

Thanks for all the feedback - it looks like everyone is doing something a bit different.

Right now I'm recording separate mono files - Most of the productions I'm working on barely get iso recording.  This makes it easier for them.

Even though it slows things down, I think I'm going to continue to record all tracks and just make sure I mark the empty files as null so post knows there isn't supposed to be anything on it.

Thanks again all!

Phil

[Darren]

Polyphonic files for dramatic shoots.  Mix on track one.  ONLY the necessary tracks are armed, with the exception of needing to accommodate some of the short comings of some of the older avids, and even then, only when there is no transfer house in the workflow.  In this case, blank tracks are labelled "BLANK TRACK", and the need for them would have been pre-explained by me during pre-production in my standard workflow letter that goes out to all of the necessary parties.

Monophonic when doing other jobs requiring 16-ish  tracks.

[Noiz2]

I noticed something that may be helpful.  I was just doing a doc and they were switching between two locations in rather unplanned ways.  The first day I ended up just recording everything to be "safe" but in testing (not during the shoot) to see if I could turn off tracks on the fly (can't) I did discover that if you don't have anything assigned to a file in BR that it creates a very small (32k) file named EMPTY.  You have to do all your un selecting before recording but you can save a pile of disk space and it's quick to do.

So what I ended up doing was leave the file count the same for all takes and just un assign the inputs that were not being used.  I haven't seen this documented so I'm not sure if it's an "official" feature.  I would vote to make it official if it isn't.  My first day was around 27gigs the second less than half and it was clear what tracks not to use.

[takev]

Hi Noiz,

The creation of an empty file was laziness on my side. Boom Recorder actually creates a proper audio file, but it never has any samples to add. It makes the code a lot cleaner as well as there is no special case for it.

I think some programs may crash if one would load such an audio file. I don't think it is explicitly written in the specification of .wav files to allow for zero channels.

Actually I currently have made a special case for it, in the new version if you don't assign channels to a file, the file will record video instead. But that is me being lazy again, I have to update the patch bay so one can assign video channels to a file.

Cheers,

    Take

[Noiz2]

Hi Noiz,

...

Actually I currently have made a special case for it, in the new version if you don't assign channels to a file, the file will record video instead. But that is me being lazy again, I have to update the patch bay so one can assign video channels to a file.

Cheers,

    Take

Take,

So would this work the same way?  Nothing assigned and no video coming in = very small file or is it  going to create a huge blank video file?

I was recording all individual files so being able to open the empty ones wasn't an issue and I deleted them before burning a disk for the production.  What was nice was it was very clear in the sound report because the file name was "EMPTY".

[takev]

I will try and make it the same as it was.

I don't yet know how to cleanly handle video files in the patch bay. I may need you to specify the file-format you want for each file, instead of a global file-format setting. And in that case I can also let one specify the bit depth for each file separately.

It seems Boom Recorder is getting more generic with each version. At some point it will probably be a complete data logging system, or a telemetry recorder. With separate plugins for audio recorder, video recorder, temperature recorder, tire pressure recorder.

Truly I am actually thinking about this, it would simplify the ring buffer a lot. Also I am thinking of making a LFE recorder by recording the sudden motion sensor, it would also allow recording from multiple audio interfaces that are not locked together.

[RPSharman]

Take,

I love the simplicity of BR.  If it becomes too over engineered, it'll be just like everything else out there.  Please keep the the sound and the sound/video assist versions separate and continue to support each.  It's bad enough we have to listen to the actors. I don't want to have to look at them too!  :-)

R

[takev]

I can understand that you don't want to see the actors when you're listening to them, but I think if I make the program more generic then the interface can become simpler as well. You simply select what kind of media (when you route a audio input, video input or tire pressure input to a channel) you want in each Boom Recorder channel, which will enable the user interface for the selected medias.

You can still route a channel into a file, depending on the file format selected you can assign a channel to it, or not. Like you can add video and audio to a QuickTime file, but a BWF file can only record audio and meta data.

Everything just becomes more direct, but I am the first to agree that the patch bay then needs a better user interface, so you can draw horizontal, vertical and diagonal lines, instead of one cell at a time.

BTW, it is not a video assist function (although in the generic version it could), it is an actual digital cinema recorder, recording the video in the highest quality. Video assist will need better transport controls, I think.

What it all comes down to is a replacement of the ring buffer that can handle all types of media at the same time.

[Sergio Sanmiguel]

That is a great Idea Take! I'm exited for video support on Boomrecorder. I was actually thinking on adding a Grass Valley ADVC55 video interface to be able to feed "videoasist" into my Powerbook, & if you can have that screen embeded into Boomrecorder (even if it doesn't actually records it) would be kind of cool...

As for the patchbay you may want to take a look at the Reason aproach of soft-bay, is My personal favorite though.

[bcopenhagen]

I'm not a Reason expert, but IMO, it wouldn't solve the issue of only patching one channel at a time.  It's still a bit tedious and time consuming, though you CAN save your patching.

Take, can you use a modifier (ie, SHIFT-click-and-drag), to assign multiple cell channels at once?

Is it possible to create separate ring buffers for video and audio?  Is the data rate for video significantly higher?  Will it need to be written to drives with a greater bandwidth than Firewire can handle?  Does the video need to have any pre-record? (I would say probably not)  If the ring buffers are combined, what would happen if the video choked up the bandwidth?  Would the audio also be at risk of aborting?  Is there a way to make them independent processes from each other so if video failed, audio would continue?

Like rpsharman, I love Boom Recorder as it is.  I exhausted my long list of requests months ago and have been content for awhile.  I think that as you develop, you shouldn't rule out the idea of creating two independent softwares, instead of mangling one in order to create a super-software that does everything.

The tire pressure recorder, though, that should be highest on the priority list. 

-Brian

[takev]

Hello Brian,

I want to implement shift+click and drag for the patch bay.

Right now there are separate ring buffers for video and audio, but this does not save you from an abort when one of them fills up. Otherwise I would have to create two transport controls one for video and one for audio as well.

The data rate for the raw video is around the maximum data rate of Firewire 800. As there is only one Firewire 800 port on a MacBook Pro and it is used to connect the camera, so you will need an external SATA disk to record 60 MByte/sec.

There are a couple of disk recorders for DV and HDV cameras right now that has pre-record function, so it may be useful. But it will eat quite a lot of memory.

Combining the ring buffers should not have any influence on bandwidth limitations, compared to separate ring buffers. I have ran Boom Recorder for 20 minutes recording internal audio and raw 60MByte/sec video, without any drop for either audio or video.

Making the recorder generic also allows features, like recording from two unlocked audio sources, to be added quite easily. It also allows for code the be exercised more, for example a new ring buffer system would handle much more data with video then for audio, and thus becomes more robust in the process.

I have thought long about making a separate video software, but then I have two pieces of software to work on, making Boom Recorder an application without any more development. Now I only have to concentrate on one application.

And I always think of you guys first, that is why the tire pressure recording is such a high priority. It will allow you to tune the tire pressure on your cart so that it will become much more stable. I've read some scientific articles from people who call them selves audiophiles, that if you mechanically stabilise your digital equipment, the jitter is noticeable lower, and thus sounds much much better.

[Sergio Sanmiguel]

...And I always think of you guys first, that is why the tire pressure recording is such a high priority. It will allow you to tune the tire pressure on your cart so that it will become much more stable. I've read some scientific articles from people who call them selves audiophiles, that if you mechanically stabilise your digital equipment, the jitter is noticeable lower, and thus sounds much much better.

Very funny Take...

Regarding drag & drop on the Boomrecorder patch bay, that's what makes Reason's patch bay so easy to handle. Its like an old telephone operators desk where you just pull the cable to the destination you need it to go to; and if you shift+click on the jack it will drop down a menu with places it can be assigned.

[takev]

Hello Sergio,

Doesn't that get a little bit cluttered when you are working with 400 patches? I now have a customer that is running with 88 channels.

There is no real limitation anymore in Boom Recorder, I can change some compile settings to go for thousands of channels, but again the ring buffer is in the way, it is already use a lot of memory for 88 channels, because it allocates memory for each channel

Cheers,

  Take

[Sergio Sanmiguel]

Yes it does get cluttered, but you have the option of turning off the animated cables for a nice clean look... In the case of Boomrecorder I don't see myself using any more than 24 channels but maybe only 8 or something like that. 

One thing that would be kind of nice to have in BR is the ability to load VST plugins like, compressors, limiters, eq and patch them at will... Am I going to crazy here?

[takev]

I am not sure about VST plugins, but I do want to at some time add CoreAudio Units, which is pretty much the same.

[Sergio Sanmiguel]

I am not sure about VST plugins, but I do want to at some time add CoreAudio Units, which is pretty much the same.

Indeed it is...  Here's a good source for AU plugins : hitsquad.com