Become a Site Supporter and Never see Ads again!

Author Topic: TUTORIAL: comparing waveforms for bit-accuracy using Sound Forge  (Read 1941 times)

0 Members and 1 Guest are viewing this topic.

Offline jerryfreak

  • No PZ
  • Trade Count: (31)
  • Needs to get out more...
  • *
  • Posts: 6205
  • The plural of anecdote is not data
This is a tutorial on how to compare two different .wav files to assure they are bit-accurate

why you would do this:
-you have a SPDIF-input enabled recording setup  (computer based, stand alone, bit bucket, etc) that youd like to qualify as actually recording the bits you send it without altering/resampling them, or without causing dropouts or dropped samples from poor buffering, etc
-you have a good recording setup, but the source material is of questionable integrity (i.e. DATs that can give different bits as a result of poor reads or inherent error correcting algorithms)

historically this dates to the early 2000s when we were qualifying devices such as pci and pcmcia soundcards, and the earliest of bit-buckets such as the nomad jukebox, microtrack, and others. Turns out its a lot harder to simply write un-bastardized data to a file without buffer errors, channel swapping, and other nasties. other manufacturers took the easy route (cough, apple even in current macbooks, cough), and resample *all* data to have a simplified sample rate match between hardware and software

this example uses two DAT transfers, the same tape transferred on two unique playback and bit-bucket setups, that 'should' yield repeatable results in a perfect world. Lets explore our imperfect world...

This is using a recent version of SoundForge (v11). The workflow should be similar in other wave editors if you can navigate the menus. Pardon my font size abuse, if you zoom out it lets the full screenshots load while keeping text readable

get your two transferred wavs loaded up



zoom in to find a similar portion near the front



zoom in to find a sample-exact portion and drop markers (these scales are slightly off though if you look close the samples are identical)



trim waveforms to same start point (don't mind that random cursor position)



copy entirety of one waveform and paste it into new window (Ctrl-E)



copy entirety of second waveform, go to the new window and select "paste special>mix"



make sure you are inverting the data from the clipboard, and that both mix levels are set to 0.0 dB



let it do its process



if the waveforms were exact, youd see zero across the entire resulting waveform
if one of the transfers had diginoise, youd see spikes of positive samples here and there
if there were dropped samples, youd see zero up to a point and then a waveform of normal-looking amplitude afterwards.

thats what we got in this case- dropped samples at the 4 minute mark



dropped samples is the most painful of waveforms to analyze as it is iterative, you have to identify what was dropped, get past it, and reinvert everything. Luckily (for this tutorial, not my sanity), we get a difficult case to work with.

Next I'm going to show you a useful method for transposing marker points from one waveform to another. We will use this often with this method.

go on your inverted waveform and drop a marker (or more than one marker)
select edit>regions list> markers to regions, then 'save as' regions list

in this example i dropped a marker where the samples started to go non-zero



then go to the other waveforms and do edit>regions list> open, and select the one you saved, you now have markers at the same point in each file. Here we can see the waveforms are identical up to the marker, then differ after the marker



Looking at the two waveforms, we can see the top one is smoother, so the bottom waveform probably has dropped samples. If we zoom out, we can find a match to confirm this fact



So im going to skip forward and pick anotehr matching spot and invert from there



resulting waveform again  shows dropped samples, albeit 20 minutes later

something is obviously wrong with my transfer setup



**This is why all recorders should be tested for bit accuracy. Anybody not doing this testing would think that setup 'sounds good is good'....when in reality samples are being dropped opening up the potential for audible errors**

That recorder is a Marantz PMD661, btw. being fed coax SPDIF from an R500. Should be bulletproof by conventional wisdom.

incidentally im seeing errors from both setups. The second inversion with the samples falling out of sync after 20 minutes was a clear drop out of about 1 second on the OTHER setup (PCM7040>PMD661), where the R500>661 setup was fine

yes i could put a 100% 'perfect' recording from both sources, but you need to find the glitches first. in this case im just going to rerun that tape on both setups and hope for something that pulls thru better with little to no errors





« Last Edit: March 29, 2020, 05:01:38 AM by jerryfreak »
Unable to post or PM due to arbitrary censorship of people the mod doesn't like. Please email me using the link in my profile if you need to connect

Offline jerryfreak

  • No PZ
  • Trade Count: (31)
  • Needs to get out more...
  • *
  • Posts: 6205
  • The plural of anecdote is not data
Re: TUTORIAL: comparing waveforms for accuracy using Soundforge
« Reply #1 on: March 29, 2020, 12:05:47 AM »
well for the sake of the tutorial, we can still look at the 20 minute portion from the second inversion where the samples match.

zoom all the way in on levels and we see an obvious glitch.


lets try to find it using soundforge's tools instead
tools>find>end of silent region. since were cruising through zeros set it to lowest threshold and maximum sensitivity



as you can see, it finds the non-zero sample in short order



drop a marker at that glitch, we can zoom in and see this one is pretty minor anyway



skip the cursor just past the errors and repeat the 'find' command

if the rest of the file is good, this is what you will see



considering most of the DATs and decks im using are 20+ years old, its rare to get completely thru with zero errors, though i have seen it before. more typically you end up with a handful, or in some cases a lot, of spots of non-zero samples. In both cases if you drop markers on all identified points and extract the regions list, you can overlay it over the actual original files and then audition all the spots to see if any of the errors were actually audible

in my text files, it would usually say something like 'DAT was transferred twice on two different setups and resulting waveforms were compared. Followed by either "no transfer errors were found" or "all transfer errors were inaudible"
« Last Edit: October 28, 2020, 03:50:35 AM by jerryfreak »
Unable to post or PM due to arbitrary censorship of people the mod doesn't like. Please email me using the link in my profile if you need to connect

Offline jerryfreak

  • No PZ
  • Trade Count: (31)
  • Needs to get out more...
  • *
  • Posts: 6205
  • The plural of anecdote is not data
Re: TUTORIAL: comparing waveforms for accuracy using Soundforge
« Reply #2 on: March 29, 2020, 12:06:02 AM »
another one ive been working on

another way to find the glitches is to zoom all the way in on levels, then just go drop markers manually. markers don't need to be super precise for these random gitches because youre auditioning them a few seconds before and after. note the dropped sample at 1h48. i zoomed in sample exact on that one since i need to cut it to the sample level and re-invert







look at these errors at repeating intervals. (this is a second inversion after sample-aligning the data after the dropped sample) looks like tape damage at a particular point. Havent seen this before. kinda reminds me of when you see a CDR corrode, it spreads like a fungus. This particular batch of tapes was particularly problematic. tapes sticking to reels, ive snapped more tapes in last week than i have in 25 years of using DAT. perhaps they were stored in hot or humid environment before they got to me.



« Last Edit: April 01, 2020, 09:48:27 PM by jerryfreak »
Unable to post or PM due to arbitrary censorship of people the mod doesn't like. Please email me using the link in my profile if you need to connect

Offline jerryfreak

  • No PZ
  • Trade Count: (31)
  • Needs to get out more...
  • *
  • Posts: 6205
  • The plural of anecdote is not data
Re: TUTORIAL: comparing waveforms for accuracy using Soundforge
« Reply #3 on: March 29, 2020, 12:06:12 AM »
reserved
Unable to post or PM due to arbitrary censorship of people the mod doesn't like. Please email me using the link in my profile if you need to connect

Offline jerryfreak

  • No PZ
  • Trade Count: (31)
  • Needs to get out more...
  • *
  • Posts: 6205
  • The plural of anecdote is not data
Re: TUTORIAL: comparing waveforms for accuracy using Soundforge
« Reply #4 on: March 29, 2020, 12:06:25 AM »
reserved
Unable to post or PM due to arbitrary censorship of people the mod doesn't like. Please email me using the link in my profile if you need to connect

Offline jerryfreak

  • No PZ
  • Trade Count: (31)
  • Needs to get out more...
  • *
  • Posts: 6205
  • The plural of anecdote is not data
Re: TUTORIAL: comparing waveforms for accuracy using Soundforge
« Reply #5 on: March 29, 2020, 12:06:38 AM »
reserved
Unable to post or PM due to arbitrary censorship of people the mod doesn't like. Please email me using the link in my profile if you need to connect

Offline jerryfreak

  • No PZ
  • Trade Count: (31)
  • Needs to get out more...
  • *
  • Posts: 6205
  • The plural of anecdote is not data
Re: TUTORIAL: comparing waveforms for accuracy using Soundforge
« Reply #6 on: March 29, 2020, 12:06:51 AM »
reserved
Unable to post or PM due to arbitrary censorship of people the mod doesn't like. Please email me using the link in my profile if you need to connect

 

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