[alex reznick]

Hi everyone

I converted the same file from 32 bit to 16 bit twice, repeatedly,
using the same dither and noise shaping, and it is quite consistent:

1) both files are NOT identical when the conversion is done in Cool
Edit Pro and Samplitude - over 12 million differences, and the delta
file looks like continuous broadband noise at -59.679 dB in Samplitude
and -78.268 dB in Cool Edit Pro

2) both files ARE identical when the conversion is done in Izotope RX

Does this mean that some programs inject randomized noise, and others
non-randomized? But then if randomization is the case, why does the
delta file show the difference in noise levels that is consistent from
pair to pair comparison?

I repeated conversion 8 times in Cool Edit, and the delta between 1 &
2, 3 & 4, 5 & 6, 7 & 8 takes is always -78.268 dB.

Can anybody explain what is going on here?

Thanks
Alex

[Arny Krueger]

"alex reznick" wrote in message
...
Hi everyone

I converted the same file from 32 bit to 16 bit twice, repeatedly,
using the same dither and noise shaping, and it is quite consistent:

1) both files are NOT identical when the conversion is done in Cool
Edit Pro and Samplitude - over 12 million differences, and the delta
file looks like continuous broadband noise at -59.679 dB in Samplitude
and -78.268 dB in Cool Edit Pro

I just did the same thing using as my 96/32 reference the 96k file from one
Alex Resnik.

I converted the file to 16 bits twice by the following means:

(1) Selected the entire 96/32 file.
(2) Did an edit, copy to new, twice
(3) Converted both file copies to 16 bits
(4) Did an edit, copy of one of the two 16 bit files.
(5) Did an edit, mix paste of the clipboard the other 16 bit file using 100%
mixing, but with the invert flags turned on.
(6) Found a residual difference of about -93 dB RMS.

Looks to me like the dither that was used in the conversion to 16 bits was
actually pseudo random, and was being taken from the same pseudo random
source at different points in its generation sequence. I used no noise
shaping. It is possible that other noise shaping would result in far larger
differences because they involve amplifying the noise to far higher
amplitudes at high frequencies.


2) both files ARE identical when the conversion is done in Izotope RX

The could achieve this by resetting the seed of their pseudo random source
at the beginning of every dither operation.

Does this mean that some programs inject randomized noise, and others
non-randomized?

Dithering is not necessarily a random process. In programs it is done via a
static algorithm, so given the identical same inputs, the results will be
identically the same.

However the noise source used may or may not produce a repeatable sequence.
It's an interesting (but in this case fairly useless) philosophical question
whether the noise source used should be more or less random. Most audio
random noise sources work about the same as long as you make their sequences
long enough that the repetitions aren't heard. this takes a sequence that is
more than a few seconds long, but less than a few minutes. That's for noise
at very audible levels. At low levels a sequence that is only a few seconds
long might suffice. A well-designed random number generator will generate a
sequence that is at least as long as the largest number that it can
generate. For 32 bits and audio frequencies, the pseudo random sequence
would be more than 4 billion (thousands of millions) samples long.

In general there are no truly random sources in the world of programming.
They all use pseudo-random noise sources. Pseudo-random noise sources are
100% predictable. They start with a seed and produce a sequence of numbers
based on it. The randomness of a pseudo random noise source can be
apparently *improved* by picking the seed from an outside source such as the
current time/date. Another equally valid approach is to just keep the pseudo
random source running based on the same seed. A third equally valid approach
would be to start with the same seed every time more random numbers are
needed. There are probably some circumstances where one of the 3 options is
better than the rest. Dithering is probably not one of them.

But then if randomization is the case, why does the
delta file show the difference in noise levels that is consistent from
pair to pair comparison?

I repeated conversion 8 times in Cool Edit, and the delta between 1 &
2, 3 & 4, 5 & 6, 7 & 8 takes is always -78.268 dB.

Can anybody explain what is going on here?

You can probably change the size of the delta by adjusting the amount and
shaping of the dither.

[alex reznick]

You can probably change the size of the delta by adjusting the amount and
shaping of the dither.

But then how could the same dither Pow-3 cause different deltas when
applied in Samplitude and Sonar?
Samplitude -59.679 dB (consistently from one conversion to another)
Sonar -60.26 (consistently)

Also, when running 32 bit to 16 bit conversion with dither in the
batch in Samplitude, I get, on average, 1 out of 10 files with a
glitch. The glitch looks like an interruption of the sound with
silence (with noise) for about half a second. It is not exactly
reproducible: each batch conversion compromises different files. Could
not find any similar complaints on Samplitude forums or Google.
When I convert without a batch - manually, file by file - there is no
such glitching.

Does this mean that batch processing uses dither differently than the
main program?

[Arny Krueger]

"alex reznick" wrote in message


You can probably change the size of the delta by
adjusting the amount and shaping of the dither.

But then how could the same dither Pow-3 cause different
deltas when applied in Samplitude and Sonar?

Same reason - different means of generating the pseudo random noise for
dithering.

Another reason - the details of the implementation of Pow-r 3 are slightly
different.

Samplitude -59.679 dB (consistently from one conversion
to another) Sonar -60.26 (consistently)

Not much of a difference in my book.

Also, when running 32 bit to 16 bit conversion with
dither in the batch in Samplitude, I get, on average, 1
out of 10 files with a glitch. The glitch looks like an
interruption of the sound with silence (with noise) for
about half a second. It is not exactly reproducible: each
batch conversion compromises different files. Could not
find any similar complaints on Samplitude forums or
Google.

That's a completely different issue that could have any number of different
causes.

When I convert without a batch - manually, file by file -
there is no such glitching.

Sounds the the batch mode stresses the machine over a period of time and
eventually it gitches.

Does this mean that batch processing uses dither differently than the main
program?

Not necessarily - the load on the system is different because the batch mode
just bangs away on the machine quite relentlessly.

[alex reznick]

When I convert without a batch - manually, file by file -
there is no such glitching.

Sounds the the batch mode stresses the machine over a period of time and
eventually it gitches.

I doubt it: this is a 4-core 2.5 GHz machine. And Samplitude is just
about the most economical DAW out there (about 3 times less CPU than
Sonar). Just one job should not cause any CPU overload. Besides,
wouldn't maxing CPU just delay the job rather than intercepting? The
only exception to that is overheating, but Intel calibrates its
hardware with the way safe margin (20 degrees or so) for this to
become an issue under normal temperature conditions.


Does this mean that batch processing uses dither differently than the main
program?

Not necessarily - the load on the system is different because the batch mode
just bangs away on the machine quite relentlessly.

Of course I will try later today to batch process video material - it
is much heavier than audio - and then run bit by bit comparison of the
files. But I doubt CPU load is the cause.

[Arny Krueger]

"alex reznick" wrote in message

When I convert without a batch - manually, file by file
-
there is no such glitching.

Sounds the the batch mode stresses the machine over a
period of time and eventually it gitches.

I doubt it: this is a 4-core 2.5 GHz machine.

One of the *joys* of multitasking operating systems is that they can become
bottlenecked even when there's unused CPU power to burn.

For openers, most software is still single-threaded which means that up to
75% of the CPU power can be idle and the system still unfortunately behaves
like it is running at 100% CPU.

And Samplitude is just about the most economical DAW out
there (about 3 times less CPU than Sonar).

Resampling tends to be CPU bound, or I/O bound depending on the basic design
and execution of the audio software.

Just one job should not cause any CPU overload.

If wishes were fishes. Ever run the XP Performance monitor software and see
what the system is doing when you run various operations? When I do this I
focus on I/O rates, swapping rates, and CPU use overall and per processor.

Besides, wouldn't
maxing CPU just delay the job rather than intercepting?

I still hear a lot of complaints about the sophistication of XP's resource
scheduling software. I've always been frustrated by PCs because they act
ugly given the resource utilization that they register. We used to run IBM
mainframes with heavy interactive loads at 100% CPU (x up to 6 processors),
heavy swapping, and with huge I/O loads for hours at a time, and they still
responded smoothly. IBM's scheduling software was very sophisticated. XP
was developed in the DEC tradition, not the IBM tradition. Back in the day I
was a system programmer for both DEC and IBM computers of roughly equivalent
MIPs and RAM. The IBM boxes could walk away from the DEC boxes when both ran
comparable workloads.

The only exception to that is overheating, but Intel
calibrates its hardware with the way safe margin (20
degrees or so) for this to become an issue under normal
temperature conditions.

Good that there aren't any thermal faults, which of course you really don't
know about for sure unless you are monitoring core temperatures in real
time.

Does this mean that batch processing uses dither
differently than the main program?

Not necessarily - the load on the system is different
because the batch mode just bangs away on the machine
quite relentlessly.

Of course I will try later today to batch process video
material - it is much heavier than audio - and then run
bit by bit comparison of the files. But I doubt CPU load
is the cause.

The video software is a different piece of software. I also run both video
and audio production on the same hardware. AFAIK my audio operations
(mostly in CEP 2.1) run faultlessly and smoothly and don't disrupt the
multitasking of the machine. My video operations (Premiere Elements) often
run well, but not always. PE has been known to make the machine catatonic
for many seconds at a time. I find no anomolies in the finished work either
audio or video. I suspect that I've had less problems multitasking PE since
I turned off swapping...

[Scott Dorsey]

alex reznick wrote:

But then how could the same dither Pow-3 cause different deltas when
applied in Samplitude and Sonar?
Samplitude -59.679 dB (consistently from one conversion to another)
Sonar -60.26 (consistently)

Because it's really not the same dither. And even if it were the same dither,
the random number generator they use in the implementation can be different.

Also, when running 32 bit to 16 bit conversion with dither in the
batch in Samplitude, I get, on average, 1 out of 10 files with a
glitch. The glitch looks like an interruption of the sound with
silence (with noise) for about half a second. It is not exactly
reproducible: each batch conversion compromises different files. Could
not find any similar complaints on Samplitude forums or Google.

That's a bug and a different issue.

When I convert without a batch - manually, file by file - there is no
such glitching.

Does this mean that batch processing uses dither differently than the
main program?

No, it means the bug only occurs under those circumstances and may not really
have anything to do with dither at all.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Dorsey]

alex reznick wrote:
Hi everyone

I converted the same file from 32 bit to 16 bit twice, repeatedly,
using the same dither and noise shaping, and it is quite consistent:

1) both files are NOT identical when the conversion is done in Cool
Edit Pro and Samplitude - over 12 million differences, and the delta
file looks like continuous broadband noise at -59.679 dB in Samplitude
and -78.268 dB in Cool Edit Pro

2) both files ARE identical when the conversion is done in Izotope RX

Does this mean that some programs inject randomized noise, and others
non-randomized? But then if randomization is the case, why does the
delta file show the difference in noise levels that is consistent from
pair to pair comparison?

That's what dithering does. This is a good thing.

I repeated conversion 8 times in Cool Edit, and the delta between 1 &
2, 3 & 4, 5 & 6, 7 & 8 takes is always -78.268 dB.

Can anybody explain what is going on here?

Check the FAQ for this group on the subject of dither.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[geoff]

alex reznick wrote:
Hi everyone

I converted the same file from 32 bit to 16 bit twice, repeatedly,
using the same dither and noise shaping, and it is quite consistent:

1) both files are NOT identical when the conversion is done in Cool
Edit Pro and Samplitude - over 12 million differences, and the delta
file looks like continuous broadband noise at -59.679 dB in Samplitude
and -78.268 dB in Cool Edit Pro

2) both files ARE identical when the conversion is done in Izotope RX

Does this mean that some programs inject randomized noise, and others
non-randomized? But then if randomization is the case, why does the
delta file show the difference in noise levels that is consistent from
pair to pair comparison?

I repeated conversion 8 times in Cool Edit, and the delta between 1 &
2, 3 & 4, 5 & 6, 7 & 8 takes is always -78.268 dB.

Can anybody explain what is going on here?


Whatever form of dither each uses, the dither waveform may start at a
difference part of it's cycle per conversion, so results will differ.

Presumably Izo uses something non-random, or 100% repeatable.

Cool Edit really is a bit ancient in terms of processing 'vintage'.

geoff