> Testing bit-accuracy doesn't require rocket
> science but it is amazing how many developers
> seem to skip even the simplest of tests
But reading what Mr Blood has to say is like entering the hall of
software shelved "Not ready for use" but we need to get some income so
we release it any way since nobody will notice the errors at all.
We feed 24 bits into the system, the system can't or choses not to
handle the extra-wide word width, truncates to 16 bits, passes the
signal through the DSP (digital signal processing) -- which we don't use
in preservation -- then applies dither on the output to pad the file
back to 24 bits before writing to the drive! Who would ever know? Who
could ever find this?
Far more troubling, as we saw in our previous example, some times the
system (and we cannot determine where in the chain this is occurring,
except that it's happening between the ADC and the hand off to the
operation system to write the file) decides to do this on the fly -- in
the middle of the file.
This is a trap in action.
As I have noted when trying out different software myself it can be very
frustrating trying to find out all the hidden gotcha´s that should not
be there no matter what.
But many software vendors are entirely unscrupulous for sure in thinking
that nobody will notice nor care.
The Mastering Room AB
E-mail: [log in to unmask]
Learn from the mistakes of others, you can never live long enough to
make them all yourself. - John Luther