I decided to take advantage of the expanded multichannel recorder and record the 7 parts I had going on ther 301 and the rest on my mtk22 (as I usually use for everything), this way I wouldn’t have to mix down on the 301 to accommodate for the four outs. Recorded the mix of 301 on the mtk22 as well, for sync-by-hand after the fact.
To my big surprise the recordings from the 301 ran out of sync with the recording from the mtk22.
Can anyone verify this?
I’d be happy to provide test files for @odevices …
Given that there is no synchronization (e.g., word clock) between the two devices, I’d say that it’s normal and expected that they would drift out of sync over time. One device is going to run a bit more slowly relative to the other, it’s not like there are atomic clocks built into these things.
Even if I recorder two tracks - one by one I have some time lag. And this is main reason for me to record all drums part in one time (old techno guys know the rule of tight timing).
miminashi is right that without sync in recording devices (like word clock) you have some difference in tracks (and this is so unpleasant to make them synced again). Soundcraft mixer and recording device (in it or laptop) can provide more latency than ER301.
Sync track from DAW to ER301 (for triggering record) can be a more fair test
Any chance for around 20 channels on the 301 recorder, obviously depending on speed of SD?
Sometimes I have many things going on the 301 and the four outs becomes the limiting factor. At 6 channels I didn’t have the mulitrack recorder,at 12 channels it’s very interesting but most of the times I’ll have to mix before recording, at 20 channels I can ditch the mtk22.
I routinely share saw sessions to/from other daws. Bounce to stems (from 0 time aka all the way to the left aka zero-adjusted) and inform the receiver of the bpm. It always works, syncs for ages. I’m a little slow on the mental drawer, but isn’t this the same thing, recording exactly 1 minute of audio in a file that is gonna play for exactly 1 minute?
No, it’s really not the same thing. It’s a fairly subtle and somewhat mind-melting concept. Colin Fraser gave a great summary of the topic on the Sequentix forum some years back, I’ll see if I can dig it up.
But the gist is, if you record 1 second of audio at 48000KHz in your DAW, you’ll end up with a file that is 48000 samples and if you drop that file in an editor it will of course be exactly 1 second long. However, this 1-second file does not necessarily represent exactly 1 second of elapsed time in the physical world. It’s only 1 second relative to the timing reference of your system clock, which is all but guaranteed to be running a little fast or a little slow within some margin of error.
The amount of drift you’re reporting does seem a bit on the high end (0.008%, or 80PPM), but it’s not orders of magnitude off from what you would expect out of the clock oscillators in an embedded system like the ER-301. Devices generally have pretty good clocks these days because they’re required to make things like USB work.
That’s an interesting topic, it’s good to know this, I had no idea this could happen.
Question: is it a progressive/variable drift or just some kind of offset than can be fixed later in Audition or another editor ? I’m asking because I’ve never experienced or noticed this before but now that you mentioned it… :-/
Yeah, frequency and time are just reciprocals of one another.
If your were to record a reference tone on two systems you would find that the pitch of the recorded signals would differ slightly between the two recordings. At least one of the clocks would have to be seriously out of whack for the difference to be perceptible as a change in pitch (unless you’re Trent Reznor). It would more likely manifest as a phase shift in the short term and then as a delay over the course of minutes or hours.
It’s progressive, so the offset grows over time. I guess an easy solution would be to chop up the recordings and manually align parts that are intended to be in sync, which would probably be okay unless the uninterrupted passages are very long.
In this case I solved it by stretching the audio recorded on the er-301 in reaper by setting a stretch marker at the very beginning and the very end and dragging the later one to match the mix out from the er-301 that I recorded on the mtk22. Stretching the audio gives a slight degradation, but this small amount is un-perceivable to my ear.
I might choose this path again (although obviously it would be great not having to deal with the audio gettin gout of sync). As mentioned, if the 301 could record all the tracks I need (I could generally live with about 20 tracks), I could record everything here and import in reaper for mixing.
EDIT: pulled you my calculator and if I’m not mistaken playing a 10mins 48000hz sample at 47999hz will make it 0.0125 secs longer (and slightly flat). Maybe I could do some kind of poor mans clock matching by messing with the sample rate before importing…
With trial and error + a bit of manual binary searching, I found that resampling the sample from the er301 to 108650 Hz and “re-interpreting” it as 108665 Hz is pretty close (those numbers are gone in the script below, they were in the first version of the script, when I didn’t realize you sox accepts fractional rates). A test recording of 65 minutes synced about 4 samples away (looking at the last impulse in my DAW). My humple ~10min recordings should be fine with this
Here’s the bash script that wraps it up (result is 16 bit 44100Hz flac), you’ll need sox installed, probably only works on linux…
for i in "$@"; do
basename=$(basename "$i" .$ext)
if [ $ext != 'wav' ]; then
sox -r 48006.6268 "$i" -r 44100 -b 16 "$flac"
You can do this with one resample instead of two. It probably doesn’t matter too much since sox is a high-quality resampler, but to maintain the highest fidelity it’s better to avoid unnecessary resampling.
Here’s an example command for a file that was recorded with a sample rate 1.5% too fast (and thus plays at a slightly lower pitch than it should):
sox -r 48720 sound01.wav -r 48000 sound01b.wav
You should refer to the section about the --rate parameter in the soxdocumentation for more details. I’d add the nominal sample rate and the scaling factor as arguments and calculate the input sample rate in the script, rather than hard-coding magic numbers which are bound to be off eventually.
Thanks for looking at the script. I was sure sox could work with fractional sample rates (hence the strange numbers to get to the correct relationship), but it turns out it does! I updated above.
I’m always recording at 44.1K 16 bits flac in my daw, I’m not gonna supply those numbers every time I run the script. I’ll leave it to the reader to mold the script in anyway they please, including making rate, bit depth and output format arguments to the script.