Become a Site Supporter and Never see Ads again!

Author Topic: Matrix Time Drift -- How Much Is Too Much  (Read 16756 times)

0 Members and 1 Guest are viewing this topic.

Offline Shadow_7

  • Trade Count: (0)
  • Taperssection Member
  • ***
  • Posts: 310
Re: Matrix Time Drift -- How Much Is Too Much
« Reply #60 on: June 10, 2010, 03:39:55 PM »
You might want to explore the File > Edit Chains feature in Audacity. Looks like it allows you to apply a sequence of operations in one action.

I might, but a lot of my edits don't lend themselves to that sort of chain.  i.e. Hard Limit depends on content (and mood).  Hard Limit + Amp + Trim is about all I normally do in audacity as far as edits go.  Everything else is more or less finding where the waveforms line up, or what the EQ looks like.  Maybe some noise removal if I'm using my cheap mics.  What would otherwise be chained is 1+ hours, sometimes close the 3 hours continuous audio and several GB in size.  So more command line tools are a better fit, after plugging in a few numbers after looking at the content in audacity.

-----

It looks like sndfile-resample isn't of much use for doing large timeshifts or speed modifications.  0.5 vs. 0.500000058 for that minor shift.  I think I've ruled out the Korg or audiogate though.  It looks like sox probably in combination with a stereo file and concat-ing several files/parts into a whole is the primary issue.  Using sndfile to do those singular tasks works better.  I've stuck sox back into the mono parts to alter speed and it does the job.  I'm liking the resampling that sndfile-resampling does at it's highest setting.  It's a major time suck, but kind of nice.  There is a minor time drift between it's lowest -c 4 and highest -c 0 settings of about 0.002 seconds.  But since all I'm doing is swapping korg audio for FH1 audio on a video, good enough.  The math even works out pretty simply.  Far less guessing / trial and error at this point.  Basically difference in the start of the camcorder segment between two sync points.  Over the length of time between those sync points.  Plus one for the speed amount number via sox.  Or 0.072/737.105 + 1 = 1.000097679 on the component I've been toying with.

Offline morst

  • I think I found an error on the internet; #UnionStrong
  • Trade Count: (2)
  • Needs to get out more...
  • *****
  • Posts: 5967
Re: Matrix Time Drift -- How Much Is Too Much
« Reply #61 on: June 27, 2010, 02:02:25 PM »
I've never tried it that way -- just always been curious about it in situations where the speed difference is so extremely small that correcting the pitch isn't a real concern. Pitch is the only concern I can think of -- I certainly don't think any of us could notice if 1 sample is removed. Anything else to worry about?

If two different clocks yield recordings of two different lengths, they will have correspondingly different pitch. Most likely, it will be too subtle to be heard with the ears though it could result in some phase shift, or beat frequency. Personally, if two signals are not within 15-20ms, I hear slap-back (delay), but below that it's pretty subtle. Unfortunately, unless the difference is microscopic, there is likely to be some phase shift audible, and that can definitely screw with bass definition and solidity

I think we are addressing a situation where there are 3 clocks involved.
1 - recorder A
2 - recorder B
3 - playback device

If there is any difference between 1 and 2 - it will result in a different pitch when played on 3 - correct?

I wonder we were able to use two discrete clocks during playback - would the sources be the same pitch?

Is there anyway to determine a given recording's "absolute" sample rate? (rather than the generic "44.1")
I think we can ignore clock #3 for our calculations. Once you set clocks 1 & 2 to remove drift, the only people who would notice the difference to clock 3 are those with micro-fine perfect pitch.

But you bring up an interesting point regarding two clocks. If you transferred your recordings into the computer via analog, then each recorder would play back its content at the proper relative clock speed (assuming temperature and other environmental factors are close enough to the same). This could theoretically eliminate the need to resample by calculation, but the drawback is that BOTH sources get resampled on transfer for this to occur.

If you wish to determine the exact drift for two devices, you can make a test signal. I built mine in audacity at 48kHz. I made 10 seconds of triangle wave at 480 Hz, then generated one hour of silence (172,800,000 samples) and followed that by 10 seconds of triangle wave at 480Hz. Once I had the file, I loaded it into one recorder, and hit play, while recording on the second deck. After the hour was complete, I loaded the new recording into the computer, and lined them up. It was very easy to tell the exact number of samples of drift, but it is not a clean ratio, by any "stretch" haha. My two main decks drift about 4.29 samples per second, which is over 15,000 samples per hour.

My next test should be to run this same signal again at different temperature levels, and see if it's close or how far off it gets with temp change.

Let's assume for a moment that this whole stretching business is just bad engineering and that the only true way to synch sources is by cutting and pasting. In order to cleanly remove drift, you'd have to cut and paste and adjust very small sections. In fact, as the section length decreases, your accuracy increases. If I recall the concept of calculus, this means that you may as well just make the section length (epsilon?) as small as possible, which just brings us back to the resample algorithm we're all discussing!!! Did I say that right? In plain English - I disagree with the notion that stretch/squash is less accurate than a chop-job. Exactly the reverse, in my opinion.
https://toad.social/@morst spoutible.com/morst post.news/@acffhmorst

kirk97132

  • Guest
  • Trade Count: (0)
Re: Matrix Time Drift -- How Much Is Too Much
« Reply #62 on: July 01, 2010, 12:18:37 PM »
Here is a method that uses different sampling rates which give a more percise control over the lengths than AA3, CEP, WL etc.  It allows up to a .001 change in the sample rate.  You will need to Download the free version of R8Brain to use this.  I'll atach the worksheet which is an XLS file.  I had to zip the file since we cannot attach XLS files here.  Hope it helps, Kirk

Offline Husker Du

  • Trade Count: (0)
  • Taperssection Regular
  • **
  • Posts: 50
Re: Matrix Time Drift -- How Much Is Too Much
« Reply #63 on: July 01, 2010, 01:25:20 PM »
Here is a method that uses different sampling rates which give a more percise control over the lengths than AA3, CEP, WL etc.  It allows up to a .001 change in the sample rate.  You will need to Download the free version of R8Brain to use this.  I'll atach the worksheet which is an XLS file.  I had to zip the file since we cannot attach XLS files here.  Hope it helps, Kirk

It's without question the best method that I know about, also.  It works flawlessly.
Neumann KM150->SD MixPre->Edirol R-44

Offline Gutbucket

  • record > listen > revise technique
  • Trade Count: (16)
  • Needs to get out more...
  • *****
  • Posts: 15721
  • Gender: Male
  • "Better to love music than respect it" ~Stravinsky
Re: Matrix Time Drift -- How Much Is Too Much
« Reply #64 on: July 22, 2010, 05:01:55 PM »
Finally got around to figuring out how to fix drift in Samplitude. Too easy.  I'm using the Samp V10 Master edition, unsure if the same tool is available in SE or the other previous versions.

The function is termed Elastic Audio and can be applied directly at the object or at the track level.   There are various options for keeping or varying pitch, quantisizing to beat markers, playing processing overhead against quality etc.  You can shrink or stretch audio by entering start and stop values, the desired length, or by snapping to markers or other objects.  Values entered are whatever units you are working in: samples, hours:min:sec, etc.  I used the highest quality setting applied as 'real time effect' at track level.  It's instantaneous but eats a few CPU cycles to do its stuff when playing back.  Value not quite right? Just re-enter a new value.

I lined up the tracks on an early transient.  Moved to the end of the show and found another transient, switched units to samples and meaured the time offset between tracks then subtracted that value from the total length of the longer track.  Entered the new value for the track length.  Done.

The transients I used were within the begining and end points of the objects so technically my simple calculation is off slightly, but not significantly.  The time difference between mic pairs themselves, due to the microphone spacing, is far greater. 
musical volition > vibrations > voltages > numeric values > voltages > vibrations> virtual teleportation time-machine experience
Better recording made easy - >>Improved PAS table<< | Made excellent- >>click here to download the Oddball Microphone Technique illustrated PDF booklet<< (note: This is a 1st draft, now several years old and in need of revision!  Stay tuned)

kirk97132

  • Guest
  • Trade Count: (0)
Re: Matrix Time Drift -- How Much Is Too Much
« Reply #65 on: July 22, 2010, 06:35:45 PM »
^^^ thanks

 

RSS | Mobile
Page created in 0.051 seconds with 34 queries.
© 2002-2024 Taperssection.com
Powered by SMF