Verified audio/DSP bugs fixed in Leopard

[mpmusicny]

Can you give a little background on this problem - some links to threads, maybe?

thanks

Malcolm

Originally Posted by postfader

Well, I'm happy to say that after being notified by Apple to re-test my bugs,
that SRC (sample rate conversion) has indeed been fixed in Core Audio in
Leopard. That is, code that Logic, Soundtrack2 Pro, Final Cut Pro (?),
or any other apps used in Core Audio, will at least benefit from the upgrade
to Leopard in this department (same for Logic 7 running on Leopard).

I feel bad though, for all those people who blithely used Logic for this
kind of DSP for the past 4+ years, since some apps like Bias Peak
have been using their own code in the app to do this kind of DSP
very accurately for some time (er - since 5.0 I think for Peak).

Well at least you can now select an alternate app within Logic 8 to use
as your audio editing application, e.g., Bias Peak, Soundtrack Pro 2 etc.

Too bad the site, SRC Comparisons has not been kept up
to date (and also does not qualify the OS the version of the app
is running on).

[Lagerfeldt]

That's very interesting news, postfader.

The SRC has been lousy in core audio, which is why I'm using Barbabatch.

[postfader]

I ran the tests that were published by the Bias engineers in their
white paper:

http://bias-inc.com/products/peakPro...WhitePaper.pdf

and then applied them to all the combinations of OS's and
audio applications we use.

Without going into the actual math/params in the MATLAB files -
the goal is to test the sample rate conversion algorithm on
difficult conversions, e.g., non-integer conversion, e.g.,
downsampling (or upsampling). Depending upon how the code manipulates/scales
sample values mathematically, there can be different kinds of
errors introduced which result in noise and/or aliasing components, etc.

I tested with the source as
a sinusoidal sweep tone at 96K (24 bit), and then downsampled to
44.1K. A spectrogram is then run on the 44.1K (24 bit) downsampled
result, Using an exponential plot with a color map, an ideal sample
rate conversion shows a clean trace = a line for the audio spectrum
rising exponentially with frequency.

The white paper may explain this better, and you can see example
graphs there. But my understanding is -
all the signal energy should be concentrated only in the line trace for
converted samples, with no energy or frequency components above
or below it (the background of the rest of the plot should be the
darkest color corresponding to no energy/no signal). Think of
a bright red line (red = highest energy) representing all samples
perfectly converted looking like the curve rising from left to right
for the natural log, "e to the X", e^^X against a dark blue
background everywhere else (minimal energy or no signal). The
X-axis is time and the y-axis is frequency (increasing from bottom
to top).

For Logic 7.2 on an older version of Tiger, e.g., I think it was maybe
10.4.6 (Tiger) or thereabouts, - there was alot of energy outside
the trace for the converted samples (noise),
and also reflections of the curve representing
the frequency sweep (unwanted frequency components from sample
rate conversion).

Listening to this result, you would not hear outright distortion, but
rather converted music would sound kind of muffled/fuzzy, and
laking in transparency. Depending upon your monitoring signal
chain, some people might not hear a marked difference (but we
did hear an obvious difference in blind A/B comparison tests
with Logic, B'Batch, Peak, etc.).

For Logic 7.2 on 10.4.10 (Tiger) there is improvement - but still some
unwanted frequency components (same for Logic 8).

But on 10.5 (Leopard), Logic 7.2 produces almost a completely clean
trace when doing the 96k to 44.1 downsample, and Logic8 actually
does a bit better. I'm not sure I can hear a difference between the
2 and Bias Peak 5.2 (which produces an absolutely clean trace).

So this is good news. We looked at buying B'Batch, but concluded
that for the money, Bias Peak was a better program.

[mpmusicny]

Thanks PF.

I don't suppose you'd be up for doing a trace for 44.1 > 48, would you?

thx

Malcolm