Topic: MixPre pre-roll time display

[GLouie]

I just figured out that if you set a pre-roll buffer in a MixPre, that the time displayed during recording (and on the file) does not take the pre-roll time into account - essentially, it displays the wrong time, offset by your selected pre-roll time. This was confirmed by SD Support.

I usually start the recorder before a concert, and manually log when events happen according to the time display, but found we were off by the pre-roll time. Admittedly, I don't really need a pre-roll and am not careful about setting one. Been using a MixPre10T since they came out and added a 10ii last year, and never knew this.

Anyone else find this odd? I would expect the time display to just start at 10s if you set a 10s pre-roll time. Didn't the 722 do this? I'll have to dig ours out and look. Firmware 7.16, the latest. Not using Timecode.

[GLouie]

LOL, I guess no one else is bothered by this!
I dug out a 722, and it does start the time count by the amount of pre-roll selected.

I suppose pre-roll is very seldom a bacon-saver and I can count on one hand where it helped over the last 20 years. Having the display time be off is a downside that I don't like, so I think I'll just set it to zero.

[DavidPuddy]

I don't use the pre-roll. Space is cheap these days, so as soon as I'm set up I hit record and let it run.

[morst]

LOL, I guess no one else is bothered by this!
I dug out a 722, and it does start the time count by the amount of pre-roll selected.

I suppose pre-roll is very seldom a bacon-saver and I can count on one hand where it helped over the last 20 years. Having the display time be off is a downside that I don't like, so I think I'll just set it to zero.

I like pre-roll in theory, for the chance that it can save the start of something when I'm inattentive.
But in practice it tends to eat power, not that I care on the MixPre, using my big ol' USB pack...
I don't make detail notes on timings, so the issue doesn't bug me (in fact I never noticed), but it would be good if they can fix it. Have you reported the bug to SD?
Other recorders make it work, for instance the Sony PCM-M10 preroll counts up the timer from 0-5 sec, and then stays at 5 sec until you release the pause.

[GLouie]

I like pre-roll in theory, for the chance that it can save the start of something when I'm inattentive.
But in practice it tends to eat power, not that I care on the MixPre, using my big ol' USB pack...
I don't make detail notes on timings, so the issue doesn't bug me (in fact I never noticed), but it would be good if they can fix it. Have you reported the bug to SD?
Other recorders make it work, for instance the Sony PCM-M10 preroll counts up the timer from 0-5 sec, and then stays at 5 sec until you release the pause.

I sent the question to SD support, and their CSR replied that I should turn preroll off if I don't like this, that's the way it works. Then asked why I was writing down timings instead of using the Report feature to log start/stop times.

File start/stop times are not useful here. If something funny happens mid-concert, I want to know when to find it later, not stop/start the recorder to get a time log?

I wonder if Paul Isaacs of SD is still around here. I must've gotten used to accurate file times displayed from using our 722s for 15 years - actually, still using them.

[hipporu]

File start/stop times are not useful here. If something funny happens mid-concert, I want to know when to find it later, not stop/start the recorder to get a time log?

Why not use Cue Marks?

CUE MARKER ICON Touch to lay a cue marker during record or playback.
Displays current cue mark point.

Cue Marks
Use cue marks to make it easy to quickly locate to points of interest.
The MixPre automatically renumbers cue marks if one is inserted
between existing cue marks to maintain their ascending numerical
order from start to finish—01, 02, 03, etc. You may have a maximum
of 99 per file.
Cues appear in numerical order in the Cue List, such as those
shown in the adjacent image.

[GLouie]

Q markers could be a possibility. However, I don't believe they get printed in the Report csv, and I don't think every 3rd party editor recognizes them.  You have to consciously punch the screen each time, then what - write down what happens at every Q mark? Seems like the same work as writing down the time and event. Also, someone else may be editing; I hand over the file and the log of times and events during the file, except now have to check for a pre-roll offset.

Easiest to forget about pre-roll, I suspect. Just like the good old days, you start recording late, you miss it!

[SMsound]

Does anyone actually use preroll for music recording?

I never do, as I am concerned that constant overwriting of the SD card while my MixPre is on standby will cause the card to fail prematurely. Am I wrong about this?

I could see how it's a useful feature if you plan to record a "I don't know when the rare bird will chirp, but when it does..." sound effect, but less useful for music.

[GLouie]

Yes, probably no one much cares about pre-roll for music recording. Maybe if you did rare bird chirps the day before and left a pre-roll on for your music session. Also, pre-roll time will change on you if you increase the sample rate. I am lazy and seldom check it.

[morst]

I never do, as I am concerned that constant overwriting of the SD card while my MixPre is on standby will cause the card to fail prematurely. Am I wrong about this?

Hm, I never thought about card wear in this context.
I had simply assumed it just buffered to RAM and wrote the bits to the SD card when the user unpaused, but if the bandwidth is approaching the SD card's write speed limit, then that might not be secure!?
Different machines might implement this differently.

[SMsound]

I never do, as I am concerned that constant overwriting of the SD card while my MixPre is on standby will cause the card to fail prematurely. Am I wrong about this?

Hm, I never thought about card wear in this context.
I had simply assumed it just buffered to RAM and wrote the bits to the SD card when the user unpaused   ......

Oh---that would be a cleverer way of implementing this, so long as they spec'd enough additional RAM for it (running out would make the machine freeze/brick until reset). You may be right---this would explain why the max pre-roll time decreases as you increase the sample rates. Strangely, one would think it would also depend hugely on the number of tracks/inputs you're recording. The write-speed would be OK assuming you can let the unit keep writing to the SD card for 2 secs after you hit the STOP button. Still, it makes me too nervous to try it unless I actually could monitor the RAM usage and make sure it was nowhere close to full.

[morst]

I never do, as I am concerned that constant overwriting of the SD card while my MixPre is on standby will cause the card to fail prematurely. Am I wrong about this?

Hm, I never thought about card wear in this context.
I had simply assumed it just buffered to RAM and wrote the bits to the SD card when the user unpaused   ......

Oh---that would be a cleverer way of implementing this, so long as they spec'd enough additional RAM for it (running out would make the machine freeze/brick until reset). You may be right---this would explain why the max pre-roll time decreases as you increase the sample rates. Strangely, one would think it would also depend hugely on the number of tracks/inputs you're recording. The write-speed would be OK assuming you can let the unit keep writing to the SD card for 2 secs after you hit the STOP button. Still, it makes me too nervous to try it unless I actually could monitor the RAM usage and make sure it was nowhere close to full.

Sony PCM-M10 flashes the card access light for a couple seconds after the STOP button is pressed.
I doubt 5 seconds of audio data would take very long to write to the card, but if it buffered the first section into RAM and was recording max tracks at max rate/depth, it might keep the RAM full the entire time?
Seems like that's an overly tight design, if that would be the case.
As for the amount of RAM, it's as much a matter of limiting the pre-roll time as it is providing enough RAM for that data.
Those two figures are very much dependent on one another, and easily calculated.
Another example: on a Behringer X32 audio console, when recording via thumb drive, the operator MUST wait until the light STOPS flashing after pressing STOP, or be forced to use data recovery techniques to get the audio!

Strangely, one would think it would also depend hugely on the number of tracks/inputs you're recording.

Not if the RAM is per track somehow