Topic: How to test for bit perfect.

[momule]

Im wondering if this Box is bit perfect
http://www.american-digital.com/prodsite/product.asp?p=890&c=188&name=Calrad10-110(coax>optical

I ran it from the UA-5 for the mule show the other night and it sounds better than the straight optical cable did as there are no pops in this one .
But I'm wondering about it being bit perfect. It sounds great , No noticable dropouts or anything weird.
so How can I test it?

TIA
Nick

[Brian Skalinder]

That looks like the ubiquitous "grey box" re-branded by a whole slew of companies, with which many have encountered difficulty using a variety of gear.  For testing bit-accuracy, do something like the following:

•   run an analog source into your UA5
•   output via both coax and optical:  optical > recorder-1 and coax > grey box > recorder-2
•   trim the resulting files from recorder-1 and -2 to the same starting and ending sample
•   use a WAV compare utility (like EAC) to determine if all samples match

You could also simply take a WAV file, play it back coax-out via a known-bit-perfect soundcard, through the grey box, to an optical recorder, and then compare the recorded file v. the original WAV on your PC.  BUT, it seems many of these digital format converters (DFCs) are device-dependent and work in some situations and not others.  Hence my recommendation above to perform the testing with the gear you plan on using in the field (i.e. UA5).

All that said, it sounds like you're having trouble running UA5 > optical > recorder:

and it [DFC] sounds better than the straight optical cable did as there are no pops in this one.

I'm assuming you've encountered pops running UA5 optical > JB3.  If you're encountering problems with this setup (or some variation thereof), there's a problem somewhere in the chain:  with your digi-modded UA5, optical cable, recorder, etc.  IMO, using the DFC is not addressing the root cause of the problems you're experiencing, it's merely side-stepping around the problem.  When encountering problems of any kind, it's best to first completely understand the root causes of the problems before identifying a solution and/or workaround.

If I were you, I'd first and foremost identify and resolve the problems running UA5 > optical > recorder.  Only then do we know whether the DFC is an appropriate solution.  For the UA5 > JB3 combo, the only real reason for a DFC, IMO, is as an additional, auxiliary optical ouput for patchers or a secondary recording device.  And personally, I'd really only consider the Hosa ODL-276 or -312 as they're proven so reliable.

[momule]

thanks Brian I'll give that a shot later this afternoon after work.

The "grey box" >Jb3 recording sounds much better than the Optical>Jb3 recording I have tracked already. as I was planning on using the optical source and keeping the Coax>"grey box">Jb3 for a backup.

I am assuming I had a "Jiggly" Optical cable out of the back of the UA-5 as the Coax version does not have these "blips" , But would rather seed the Optical if possible as I know its bit perfect.

Im looking around for a used Hosa ODL-276. as Im thinking since I have both Jb3 and as finicky as they are why not run both just in case.

again thanks for the explanation/help  Brian.  +T
Nick

[Brian Skalinder]

I am assuming I had a "Jiggly" Optical cable out of the back of the UA-5 as the Coax version does not have these "blips" , But would rather seed the Optical if possible as I know its bit perfect.

Try a different, known-good optical cable, take any potentially problematic optical adapters out of the equation, and ensure the cable is fully seated in the UA5 and JB3 and I bet the problems go away.

FWIW, if you have a "bit perfect" UA5 > JB3 recording with artifacts (clicks, pops, dropouts, etc., that effectively make it *not* bit-perfect) and a questionably bit-perfect UA5 > DFC > JB3 recording that sounds totally clean and artifact-free, I'd seed the UA5 > DFC > JB3 recording.

[SparkE!]

When testing for "bit perfect" it may be difficult to record exactly the same file to two different devices simply because it takes some time for a recorder to lock to the incoming S/PDIF signal.  That's not the problem that you should be concerned with.  What you should be concerned with is that once the recorder is locked to the S/PDIF signal, it doesn't make any alterations to the subsequent bit stream.

So, I'd recommend making one recording directly from the digital source and another through the box you want to test.  Then, with a bit literal editor such as CoolEdit or Soundforge, edit out the start and end of both files so that they contain exactly the same number of samples and that they cover exactly the same time period.  So, you start from some identifiable sample and make both files exactly the same length.

Then, you can use EAC to test the files for differences or you can invert one and add it to the other.  The result should be absolute silence with all samples set to 0.

Please note that Audacity cannot be used for bit perfect editing since it always dithers on saving the file to disk.  You can save the same file many times and never get an exact duplicate, due to the dithering.  I have not found a way to turn off dithering when saving a file in Audacity.  Sometimes dithering is desireable, but it isn't desireable if you are only trying to trim the start and end of a recording.  It's only desireable if you have done other things like equalizing, normalizing or compressing the signal.  (If someone knows how to turn the dithering on save off in Audacity, I'd love to hear from you.)

[Brian Skalinder]

When testing for "bit perfect"... [snip]Then, you can use EAC

Is there an echo in here? 

Please note that Audacity cannot be used for bit perfect editing since it always dithers on saving the file to disk.

Huh.  I did not know that - very interesting.  Big thanks for the tip, many folks will be interested to know - mind if I quote your post in a new thread in the Comp Recording forum to make people aware?

[momule]

thanks for the help sparkE.

Intresting bit about Audicity,

+t # 12 headed your way
Nick

[SparkE!]

mind if I quote your post in a new thread in the Comp Recording forum to make people aware?

That would be fine Brian.  What would be even cooler is if someone actually knows how to get around the automatic dithering issue, though.  I love Audacity for its ($0) price, but it irritates me that it dithers without permission.

[Lil Kim Jong-Il]

Please note that Audacity cannot be used for bit perfect editing since it always dithers on saving the file to disk.  You can save the same file many times and never get an exact duplicate, due to the dithering.

You need to set your working project quality to 16-bit before importing/exporting 16-bit tracks (24 bit for 24-bit tracks).  If left at the installation default setting, audacity converts the imported track to 32-float in the working buffer.  The representation conversion error at import and again at export is what is causing it to appear that dithering is being performed.

try:  Audacity Preferences > Quality > Default Sample Format and set to 16-bit



see: http://taperssection.com/index.php?topic=35937.msg458194#msg458194

[SparkE!]

Thanks for the clarification on Audacity's settings.  I thought that I had tried that before.

Point of clarification:

When set to 32 bit, the dithering occurs on export, not on import.  I can import 2 identical files into 2 separate tracks at 32 bits, invert 1 of them and mix down, ending up with dead silence.  But if I export that dead silence to a 16 bit wav file, it's no longer dead silence.

[SparkE!]

I forgot to mention that I tried Maynard G. Beatnik's trick of changing the File/Preferences/Quality/Default Sample Format to 16 bit.  He is correct that there is no dither on File/Export as WAV when that setting has been made.

[hexyjones]

What about "Import" vs "Open"? Do they handle the dithering differently?

You may have been reading the same posts as me on the Audacity list

By default, Audacity converts to 32-bit floating point on import, so
that it can do all its editing in 32-bit format.  This minimizes
rounding and quantization errors during editing.  However, it means that
the audio has to be converted back to 16-bit format on export.

Audacity uses dithering during this process to reduce quantization
artifacts.  The dithering introduces a tiny amount of noise into the
file; it can be changed or disabled in the "Quality" preferences.

Audacity's conversion routines can also introduce rounding errors, which
will cause some samples to be slightly different after a round-trip
conversion.  This is a tradeoff; it is possible to avoid this, but only
if you allow some values to be clipped on either import or export.

If you set Audacity to use 16-bit samples internally ("Default sample
format" in the Quality preferences), then you will avoid all of these
conversion and dithering issues, so you can export a perfect copy of
the imported track.  (But this setting will cause more noise to be
introduced if you actually edit any samples.)

[Lil Kim Jong-Il]

I believe that when you select that quality setting, you are selecting the format for the project working data.  If you import a 16-bit file into a project that is configured for 32-float, the imported fiile should be converted to the working format of 32-float.  It is possible that there is no error introduced during import.  But if the working data format differs from the stored format, then the data gets converted in both directions.

Also, I would tend to not call this effect dithering.  Dithering is a specific type of algorithm used to introduce noise.  I think this is just the effects of rounding error when performing data format conversion, so not really dithering in a pedantic sense.

When you say "dead silence", is that determined by listening or did you test the resultant file to be fully null?  I ask because I examined the data output from my tests and the error seemed to be within the range of +/- 4.  If there was error on import conversion and it was within this range, the sum of the wave and it's inverse would produce a non-null result but one that is very likely below the noise floor of your playback system.  


--------
Corkscrew posted before I could finish typing.  I didn't see that list but that quote confirms my assumption.

In that post, "this setting will cause more noise to be introduced if you actually edit any samples" does not apply to our most basic editing needs.  The editing they have in mind is mixing and effects.  If one is "editing" to only trim the edges and break a longer wave into tracks, then you won't experience any errors.  One should use the 32-float for blending a matrix or pitch correction type of work where the result is expected to be an entirely different wave.

[hexyjones]

By "more noise" - I think the author meant "more noise in comparison to 32 bit.."

One thing to note - Audacity chops any given wav up into a bunch of little segments that are stored in the temp folder...so when you edit, you only use the segments that relate to your selection...the rest are untouched.

[SparkE!]

Also, I would tend to not call this effect dithering.  Dithering is a specific type of algorithm used to introduce noise.  I think this is just the effects of rounding error when performing data format conversion, so not really dithering in a pedantic sense.

When you say "dead silence", is that determined by listening or did you test the resultant file to be fully null?  I ask because I examined the data output from my tests and the error seemed to be within the range of +/- 4.  If there was error on import conversion and it was within this range, the sum of the wave and it's inverse would produce a non-null result but one that is very likely below the noise floor of your playback system. 


--------
Corkscrew posted before I could finish typing.  I didn't see that list but that quote confirms my assumption.

In that post, "this setting will cause more noise to be introduced if you actually edit any samples" does not apply to our most basic editing needs.  The editing they have in mind is mixing and effects.  If one is "editing" to only trim the edges and break a longer wave into tracks, then you won't experience any errors.  One should use the 32-float for blending a matrix or pitch correction type of work where the result is expected to be an entirely different wave.

No, actually it IS dithering.  If you export to 16 bit WAV twice from the same file, you will get 2 files that are not identical.

Yes, when I say dead silence, I mean that all samples are identical to 0.  When you export that file to 16 bit WAV, it does not result in a file that is all 0's.

The moral of the story is if you want bit perfect trimming, do it in 16 bit mode.  If you are equalizing, normalizing, mixing multiple sources, compressing or anything else that involves math on the waveform, then 32 bit mode is probably the way to go.  Just realize that Audacity will dither when you export to 16 bit.