Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Hi Rez vs Redbook in Classical music (Read 41294 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Hi Rez vs Redbook in Classical music

Reply #25 –
Please use the new abx plugin that was linked to before. Also since we don't know what your playback chain does to different samplerates the sample i provided back to 24/192 could be fun.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Hi Rez vs Redbook in Classical music

Reply #26 –
Quote from: Wombat on
Quote from: Arnold B. Krueger on
Quote from: Wombat on
I uploaded a version done by SoX from the 24/192 -> 16/44.1 and back again to 24/192 for easy comparing.
http://www.hydrogenaud.io/forums/index.php?showtopic=108763



I came up with these parameters for Sox (a 1 line .bat file) to do a good job of approximating a combination of good mastering practices with modern shaped dither,  and a reconstruction filter typical of a good modern DAC:

sox %1 -b 16 %1_1644_outfile.wav rate -h -L -s -b 93 44100 dither -s -f lipshitz

You can spare the -L because it defaults to linear, -s is not needed because you overwrite it later with the -b option.
I like the Shibata dither curves more. Maybe because i still know Naoki from the nspsytune discussions years ago
Also -a for dither works nicely to prevent the dithering of silence. I use aliasing because SoX only aliases "above" the passband. When we use a slow filter the energy of the aliasing at 22kHz is very low already and even drowns in dithernoise mostly. I don't know if very strong shaped dither harms under some circumstances so the low Shibata curve is enough i guess. -b 92 prevents everything below 20khz
So i use rate -b 92 -a -v 44100 dither -a -f low-shibata
-v may be overkill but why not.
Like always with such things there is most likely as many opinions as people.

Thank you for all the tips! I also did a conversion in Izotope inside SoundForge.
For the Bit Depth converstion, Dither Mode was "MBIT+" (I don't know what that means), "Light" Noise Shaping, Dither Amount was "Normal".
For the resampling, used Izotope SRC tool inside SoundForge, on "Highest Quality" settings, which they interpret as Steepness 150, Max Filter Length 500,000 , Cutoff Scaling 1.00, Alias Suppression 200, Prering % is 100.
An ABX with the Izotope conversion was 9/10 correct, so I'm assuming there were more conversion artifacts here than with SoX, not bothering to post unless someone wants to use it.

Hi Rez vs Redbook in Classical music

Reply #27 –
Quote from: Wombat on
Please use the new abx plugin that was linked to before. Also since we don't know what your playback chain does to different sample rates the sample i provided back to 24/192 could be fun.

Yikes -- now there's a problem. I now have the newest foobar 1.3.8, and the newest ABX Comparator from here: http://www.foobar2000.org/components/view/foo_abx

And now there's an audible momentary high pitch sound whenever it switches files, just before playback begins, and no audible sound when it doesn't switch, i.e. it's telling me outright when X is the same (or different) as the previous file played. My previous ABX did not do this. So that's a broken test instrument, any workarounds welcome:

The following is just to show that the high-pitch sound is signaling what I think it's signaling:
foo_abx 2.0 report
foobar2000 v1.3.8
2015-03-28 14:31:49

File A: Beeth_192.wav
SHA1: 9c4abcf01046b2f9936ca4367c6319f59cdec7d5
File B: Beeth_44.wav
SHA1: d6b2ddc0bcdd6c389d57da6b3c377ab4c8cceca4

Output:
DS : Primary Sound Driver
Crossfading: NO

14:31:49 : Test started.
14:32:12 : 01/01
14:32:20 : 02/02
14:32:26 : 03/03
14:32:46 : 04/04
14:33:03 : 05/05
14:33:13 : 06/06
14:33:22 : 07/07
14:33:35 : 08/08
14:33:44 : 09/09
14:34:03 : 10/10
14:34:03 : Test finished.

----------
Total: 10/10

Skeptics: Would a deliberate faker reveal faulty tool in this way?
 

Hi Rez vs Redbook in Classical music

Reply #28 –
Quote from: UltimateMusicSnob on
Quote from: Wombat on
Please use the new abx plugin that was linked to before. Also since we don't know what your playback chain does to different sample rates the sample i provided back to 24/192 could be fun.

Yikes -- now there's a problem. I now have the newest foobar 1.3.8, and the newest ABX Comparator from here: http://www.foobar2000.org/components/view/foo_abx

And now there's an audible momentary high pitch sound whenever it switches files, just before playback begins, and no audible sound when it doesn't switch, i.e. it's telling me outright when X is the same (or different) as the previous file played. My previous ABX did not do this.


Are you comparing the 44.1kHz file to the 192kHz file when that happens?  Are you sure your sound card is even capable of doing that transparently?  Most are not.

Edit:  Well most that don't just resample everything.

Hi Rez vs Redbook in Classical music

Reply #29 –
Quote from: UltimateMusicSnob on
And now there's an audible momentary high pitch sound whenever it switches files, just before playback begins, and no audible sound when it doesn't switch

That's alarming. Which sound card or DAC are you using?

You should use Wombat's file or resample your 44.1 kHz file back to 192 kHz yourself anyway at the moment since there is a delay difference when sample rate changes between A/B and X revealing the file's identity. I'm pretty sure the same problem was already in foo_abx v1.3.4 but I can't find the old component to verify.

Hi Rez vs Redbook in Classical music

Reply #30 –
Quote from: saratoga on
Quote from: UltimateMusicSnob on
Quote from: Wombat on
Please use the new abx plugin that was linked to before. Also since we don't know what your playback chain does to different sample rates the sample i provided back to 24/192 could be fun.

Yikes -- now there's a problem. I now have the newest foobar 1.3.8, and the newest ABX Comparator from here: http://www.foobar2000.org/components/view/foo_abx

And now there's an audible momentary high pitch sound whenever it switches files, just before playback begins, and no audible sound when it doesn't switch, i.e. it's telling me outright when X is the same (or different) as the previous file played. My previous ABX did not do this.


Are you comparing the 44.1kHz file to the 192kHz file when that happens?  Are you sure your sound card is even capable of doing that transparently?  Most are not.

Edit:  Well most that don't just resample everything.

I'm using an RME Babyface for sound: http://www.rme-audio.de/en/products/babyface.php

It was not having any problems before the change in ABX plugin software.

Hi Rez vs Redbook in Classical music

Reply #31 –
Quote from: UltimateMusicSnob on
I'm using an RME Babyface for sound: http://www.rme-audio.de/en/products/babyface.php


That doesn't really answer my question.  If you're trying to compare a 44.1kHz sampling rate file to a 192kHz sampling rate file, a couple of things are necessary:

1)  Your card has to support switching between those sampling rates
2)  Your card has to be able to switch between those sampling rates transparently, which will mean rapidly and glitchlessly reclocking a PLL.

Have you verified these things?

Hi Rez vs Redbook in Classical music

Reply #32 –
Quote from: saratoga on
Quote from: UltimateMusicSnob on
I'm using an RME Babyface for sound: http://www.rme-audio.de/en/products/babyface.php


That doesn't really answer my question.  If you're trying to compare a 44.1kHz sampling rate file to a 192kHz sampling rate file, a couple of things are necessary:

1)  Your card has to support switching between those sampling rates
2)  Your card has to be able to switch between those sampling rates transparently, which will mean rapidly and glitchlessly reclocking a PLL.

Have you verified these things?

I don't have lab equipment to see whether the interface actually does what it says it does. I do read this at the product description:

    Sample rates up to 192 kHz on all I/Os (including two ADAT channels via SMUX4)
    Two digitally controlled microphone preamps in high-end quality
    Two balanced universal inputs for line and instrument signals
    SteadyClock for maximum jitter suppression and clock refresh
    Direct operation with rotary encoder and keys
    TotalMix FX: Newly developed internal DSP high-end mixer
    Full mobility by bus powered operation
    DIGICheck, RME's unique meter and analysis tool included
    Peak and RMS are hardware-calculated for all channels

...and of course it wasn't glitching before, whatever that indicates.

Hi Rez vs Redbook in Classical music

Reply #33 –
Quote from: UltimateMusicSnob on
I don't have lab equipment to see whether the interface actually does what it says it does.


Neither of those things will be listed in the product documentation.  Thats a device meant for playing and recording audio, not sampling rate testing.  You'll have to do these measurements yourself.I would start by checking that the interface you are using can operate at both 44.1k and 192k.  Thats the absolute minimum requirement before you can begin this test, since if the card can't do both of those sampling rates, its not going to work.

Alternatively, you can do as was suggested above and run the test using a common sampling rate that you know the device can clock at.  This is probably the better option unless you are interested in putting a lot more effort into this test.

Hi Rez vs Redbook in Classical music

Reply #34 –
Quote from: saratoga on
Quote from: UltimateMusicSnob on
I don't have lab equipment to see whether the interface actually does what it says it does.


Neither of those things will be listed in the product documentation.  Thats a device meant for playing and recording audio, not sampling rate testing.  You'll have to do these measurements yourself.I would start by checking that the interface you are using can operate at both 44.1k and 192k.  Thats the absolute minimum requirement before you can begin this test, since if the card can't do both of those sampling rates, its not going to work.

Alternatively, you can do as was suggested above and run the test using a common sampling rate that you know the device can clock at.  This is probably the better option unless you are interested in putting a lot more effort into this test.

Of course, I didn't buy the RME for testing, just as you say for playing and recording, so I may be out of luck. If you don't mind pointing me in the right direction, how might I determine that it operates at both 44.1 and 192k. Since it is fully I/O capable in both those rates, there's a distinction here that I'm missing.

My interest in testing is in 44.1/16 **as** 44.1/16, stored in that format and played back as that format, vs. other resolutions (and good MP3 encodings), in **those** formats and played back as those formats. I see the logic of the workaround, but double conversion defeats the purpose as far as I'm concerned.

Hi Rez vs Redbook in Classical music

Reply #35 –
Quote from: UltimateMusicSnob on
Of course, I didn't buy the RME for testing, just as you say for playing and recording, so I may be out of luck. If you don't mind pointing me in the right direction, how might I determine that it operates at both 44.1 and 192k.


Start with RMAA testing of those sampling rates.  Make sure they work.

Quote from: UltimateMusicSnob on
I see the logic of the workaround, but double conversion defeats the purpose as far as I'm concerned.


Curious what your logic here is?

Hi Rez vs Redbook in Classical music

Reply #36 –
Quote from: UltimateMusicSnob on
I see the logic of the workaround, but double conversion defeats the purpose as far as I'm concerned.

Whether you realize it or not, you're stating that you don't care if the difference you're hearing is solely the result of your hardware; having nothing to do with the samples themselves besides their respective formats.

Hi Rez vs Redbook in Classical music

Reply #37 –
Indeed, if you are willing to accept that downsampling is a transparent process, it seems strange to believe that upsampling would not be.  Particularly given that your DAC will up sample during playback even when operated at 44.1kHz

Hi Rez vs Redbook in Classical music

Reply #38 –
Quote from: saratoga on
Quote from: UltimateMusicSnob on
Of course, I didn't buy the RME for testing, just as you say for playing and recording, so I may be out of luck. If you don't mind pointing me in the right direction, how might I determine that it operates at both 44.1 and 192k.


Start with RMAA testing of those sampling rates.  Make sure they work.

Quote from: UltimateMusicSnob on
I see the logic of the workaround, but double conversion defeats the purpose as far as I'm concerned.


Curious what your logic here is?

RMAA - Excellent, thanks for the reference.
RMAA reports the various bit depths and sample rates are supported in full Duplex, from 8 bits to 32, from 44.1 to 192 kHz. 352.8 and 384 not supported, but I already knew that.

The premise is that D/A converters are not perfectly transparent; nor are downsampling algorithms. For example, I notice that reducing bit depth in Izotope involves choices about dithering and noise shaping; resampling involves choices about filtering parameters. The algorithms used to upsample don't simply reproduce a 44.1/16 step function at a higher resolution; they interpolate. So if the sound of 44.1/16 played *as* a 44.1/16 file by associated appropriate D/A devices is interesting (it is to me), then upsampling it back to 192/24 removes the possibility of testing the actual 44.1/16 D/A-converted sound, and instead introduces **two** rounds of potential distortion (one down, plus one back up).
  Upsampling 'solves' the device playback audible switching problem, but does so by avoiding precisely the output that I'd like to test.

Hi Rez vs Redbook in Classical music

Reply #39 –
Quote from: greynol on
Quote from: UltimateMusicSnob on
I see the logic of the workaround, but double conversion defeats the purpose as far as I'm concerned.

Whether you realize it or not, you're stating that you don't care if the difference you're hearing is solely the result of your hardware; having nothing to do with the samples themselves besides their respective formats.

Look at the post I just put up for details. I care that the hardware/software makes a difference for different formats. And it *does* matter what's in the samples; that's what the point about up- and down- conversion algorithms and interpolation goes to.

Hi Rez vs Redbook in Classical music

Reply #40 –
Quote from: saratoga on
Indeed, if you are willing to accept that downsampling is a transparent process, it seems strange to believe that upsampling would not be.  Particularly given that your DAC will up sample during playback even when operated at 44.1kHz

?  I think that neither downsampling nor upsampling is transparent. Downconverting entails a lot of parameter choices in Izotope and other tools. This actually raises a much broader aspect. Rather than starting with 192/24 and downconverting, an ideal comparison would be between two pristine captures of the same acoustic signal produced live in a single test performance, one entering the microphone and going into the 192/24, the other entering precisely the same microphone and going into the 44.1/16. Same performance, same pristine microphone/s (stereo capture), perfect signal splitting (not possible, but probably close enough), and then the processing differs at A/D stages which are *not* doing precisely the same operations. THAT would be interesting to test, but I haven't come across such a pair.

On the practical side, recording engineers do actually capture at higher resolutions, and DAWs perform their signal manipulations at higher resolutions, and the product is then downconverted for distribution.

Hi Rez vs Redbook in Classical music

Reply #41 –
Quote from: UltimateMusicSnob on
RMAA reports the various bit depths and sample rates are supported in full Duplex, from 8 bits to 32, from 44.1 to 192 kHz. 352.8 and 384 not supported, but I already knew that.


That is not what I was suggesting you use RMAA for.  All those numbers mean is that Windows is capable of playing back those formats, not that your hardware is.  This is not a useful thing to know.  Like I said before, this is something that you must measure.  RMAA is a tool for performing those measurements.  Do frequency response tests at each of the sampling rates you want to use and verify that they work correctly. 

Quote from: UltimateMusicSnob on
The premise is that D/A converters are not perfectly transparent; nor are downsampling algorithms. For example, I notice that reducing bit depth in Izotope involves choices about dithering and noise shaping; resampling involves choices about filtering parameters. The algorithms used to upsample don't simply reproduce a 44.1/16 step function at a higher resolution; they interpolate.


Well yes, given that upsampling/downsampling is a form of interpolation, I would hope that they interpolate.  But so what?  This is something you can measure.  And you should probably do that given that you are already forced into downsampling.

Quote from: UltimateMusicSnob on
So if the sound of 44.1/16 played *as* a 44.1/16 file by associated appropriate D/A devices is interesting (it is to me), then upsampling it back to 192/24 removes the possibility of testing the actual 44.1/16 D/A-converted sound, and instead introduces **two** rounds of potential distortion (one down, plus one back up).


The test you intend to do involves measuring essentially every possible step of the process, and then by process of elimination, prove that a difference you hear could only be caused by the format and not the hardware or methodology.  If you use a downsampling/upsample step, you merely have to verify that the resampling is sufficiently accurate that the performance of your DAC limits the accuracy.  This is relatively easy.  If you use two different sampling rates, you will have to verify that the hardware's sampling rate conversion or switching (which ever it uses) is transparent.  This is probably a lot harder, particularly since you don't appear to have experience measuring hardware performance, using RMAA, or have access to lab equipment. 

Quote from: UltimateMusicSnob on
Upsampling 'solves' the device playback audible switching problem, but does so by avoiding precisely the output that I'd like to test.


It doesn't solve or avoid anything.  It just exchanges one problem you probably are not equipped to deal with for one that will be easier.  The outcome is the same though, assuming you do the work for either method.

Hi Rez vs Redbook in Classical music

Reply #42 –
Quote from: Wombat on
Quote from: Arnold B. Krueger on
Quote from: Wombat on
I uploaded a version done by SoX from the 24/192 -> 16/44.1 and back again to 24/192 for easy comparing.
http://www.hydrogenaud.io/forums/index.php?showtopic=108763



I came up with these parameters for Sox (a 1 line .bat file) to do a good job of approximating a combination of good mastering practices with modern shaped dither,  and a reconstruction filter typical of a good modern DAC:

sox %1 -b 16 %1_1644_outfile.wav rate -h -L -s -b 93 44100 dither -s -f lipshitz

You can spare the -L because it defaults to linear, -s is not needed because you overwrite it later with the -b option.
I like the Shibata dither curves more. Maybe because i still know Naoki from the nspsytune discussions years ago
Also -a for dither works nicely to prevent the dithering of silence. I use aliasing because SoX only aliases "above" the passband. When we use a slow filter the energy of the aliasing at 22kHz is very low already and even drowns in dithernoise mostly. I don't know if very strong shaped dither harms under some circumstances so the low Shibata curve is enough i guess. -b 92 prevents everything below 20khz
So i use rate -b 92 -a -v 44100 dither -a -f low-shibata
-v may be overkill but why not.
Like always with such things there is most likely as many opinions as people.

What settings did you use to upconvert back to 192/24, if you don't mind sharing?

Hi Rez vs Redbook in Classical music

Reply #43 –
"since you don't appear to have experience measuring hardware performance, using RMAA, or have access to lab equipment. "

Not only do I not appear to, I said as much (that's why I said thank you for the RMAA--apologies for not having learned it in a few minutes in one evening!)

Hi Rez vs Redbook in Classical music

Reply #44 –
Quote from: Wombat on
Quote from: Arnold B. Krueger on
Quote from: Wombat on
I uploaded a version done by SoX from the 24/192 -> 16/44.1 and back again to 24/192 for easy comparing.
http://www.hydrogenaud.io/forums/index.php?showtopic=108763



I came up with these parameters for Sox (a 1 line .bat file) to do a good job of approximating a combination of good mastering practices with modern shaped dither,  and a reconstruction filter typical of a good modern DAC:

sox %1 -b 16 %1_1644_outfile.wav rate -h -L -s -b 93 44100 dither -s -f lipshitz

You can spare the -L because it defaults to linear, -s is not needed because you overwrite it later with the -b option.
I like the Shibata dither curves more. Maybe because i still know Naoki from the nspsytune discussions years ago
Also -a for dither works nicely to prevent the dithering of silence. I use aliasing because SoX only aliases "above" the passband. When we use a slow filter the energy of the aliasing at 22kHz is very low already and even drowns in dithernoise mostly. I don't know if very strong shaped dither harms under some circumstances so the low Shibata curve is enough i guess. -b 92 prevents everything below 20khz
So i use rate -b 92 -a -v 44100 dither -a -f low-shibata
-v may be overkill but why not.
Like always with such things there is most likely as many opinions as people.



You might find this comparison interesting:

Uploads forum pictures of Sox and CEP resampling

Hi Rez vs Redbook in Classical music

Reply #45 –
Quote from: UltimateMusicSnob on
Quote from: saratoga on
Indeed, if you are willing to accept that downsampling is a transparent process, it seems strange to believe that upsampling would not be.  Particularly given that your DAC will up sample during playback even when operated at 44.1kHz


?  I think that neither downsampling nor upsampling is transparent.


There are two kinds of transparency. One involves numeric perfection, and one involves subjective perfection.

I can guarantee you that not a lot of meaningful processing is numerically perfect, which is BTW also called "Bit perfect".

I can similarly guarantee you that a lot of meaningful processing is subjectively perfect, which is BTW also called "Sonic Transparency"

Quote
Downconverting entails a lot of parameter choices in Izotope and other tools. This actually raises a much broader aspect. Rather than starting with 192/24 and downconverting, an ideal comparison would be between two pristine captures of the same acoustic signal produced live in a single test performance, one entering the microphone and going into the 192/24, the other entering precisely the same microphone and going into the 44.1/16. Same performance, same pristine microphone/s (stereo capture), perfect signal splitting (not possible, but probably close enough), and then the processing differs at A/D stages which are *not* doing precisely the same operations. THAT would be interesting to test, but I haven't come across such a pair.


Its been done many times on the recording forums.

In sighted evaluations these files always sound different.

In double blind, level matched, time-synched tests, not so  much.

Quote
On the practical side, recording engineers do actually capture at higher resolutions, and DAWs perform their signal manipulations at higher resolutions, and the product is then downconverted for distribution.


OK it can and often is done. BTW I'm a part time professional recording engineer, plying the  academic music festival and religious live performance trade.

The relevant question to me is it sonically significant or is it just shuffling a lot of numbers unnecessarily?

Hi Rez vs Redbook in Classical music

Reply #46 –
Quote from: UltimateMusicSnob on
Quote from: Wombat on
Please use the new abx plugin that was linked to before. Also since we don't know what your playback chain does to different sample rates the sample i provided back to 24/192 could be fun.

Yikes -- now there's a problem. I now have the newest foobar 1.3.8, and the newest ABX Comparator from here: http://www.foobar2000.org/components/view/foo_abx

And now there's an audible momentary high pitch sound whenever it switches files, just before playback begins, and no audible sound when it doesn't switch, i.e. it's telling me outright when X is the same (or different) as the previous file played. My previous ABX did not do this. So that's a broken test instrument, any workarounds welcome:


The problem is common and the workaround is to upsample both files to the same sample rate after you do the processing of interest.

We even had a variation of this problem with pure hardware ABX comparators back in the late 1970s.

It led to the following comments in Clark's 1982 JAES paper about ABX:

"
REFINEMENTS TO THE A/B TEST
The author's first experience with double-blind audibility testing was as a member of the SMWTMS Audio Club in early 1977. A button was provided which would select at random component A or B. Identifying one of these, the X component was greatly hampered by not having the known A and B available for reference.

This was corrected by using three interlocked pushbuttons, A, B, and X. Once an X was selected, it would remain that particular A or B until it was decided to move on to another random selection.

However, another problem quickly became obvious. There was always an audible relay transition time delay when switching from A to B. When switching from A to X, however, the time delay would be missing if X was really A and present if X was really B. This extraneous cue was removed by inserting a fixed length dropout time when any change was made. The dropout time was selected to be 50 ms which produces a slight consistent click while allowing subjectively instant comparison.
"

There is a hardware ABX comparator, several 100 of which were built and sold by QSC in the 1990s. It had a similar but mechanical tell - I can take mine and read its list of unknowns with no other equipment attached. If you want a DBT put it across the room! ;-)

Hi Rez vs Redbook in Classical music

Reply #47 –
Quote from: Arnold B. Krueger on
You might find this comparison interesting:

Uploads forum pictures of Sox and CEP resampling

Quote from: Arnold B. Krueger on
Ringing anybody? ;-)

Not sure what you're getting at there.  The SoX and Audacity impulse responses show a sinc function: i.e the IDFT of an ideal low-pass response (of course, in reality, the sinc is windowed, giving the actual frequency response a non-zero transition length).  If you look at the impulse response for any of the resamplers at http://src.infinitewave.ca/ you'll see similar in almost all cases.

BTW, Audacity since v2.03 uses the SoX resampler internally, as explained here: http://wiki.audacityteam.org/wiki/Libsoxr

Surprisingly, the SRC comparison site doesn't seem to have an entry for CEP; perhaps you could make a submission for it (per http://src.infinitewave.ca/faq.html ).

Hi Rez vs Redbook in Classical music

Reply #48 –
Quote from: bandpass on
Quote from: Arnold B. Krueger on
You might find this comparison interesting:

Uploads forum pictures of Sox and CEP resampling

Quote from: Arnold B. Krueger on
Ringing anybody? ;-)

Not sure what you're getting at there. 


Sox rings worse than it may need to.

Quote
The SoX and Audacity impulse responses show a sinc function: i.e the IDFT of an ideal low-pass response (of course, in reality, the sinc is windowed, giving the actual frequency response a non-zero transition length).


Ideal is a big word. In this case I would say that the ideal low pass filter is the one that intrudes the least on the music, not necessarily some hyper simplistic rectangular bandpass and stop band design.

Quote
If you look at the impulse response for any of the resamplers at http://src.infinitewave.ca/ you'll see similar in almost all cases.


The testing there is far from exhaustive.  Some of the products have relevant user-adjustable parameters that aren't tested over their range, and the tests don't say what the parametres were for the tests.  I have to admit I was more impressed before I started my last round of investigations of the potential audible consequences.

Quote
BTW, Audacity since v2.03 uses the SoX resampler internally, as explained here: http://wiki.audacityteam.org/wiki/Libsoxr


The performance seems to bear that out.  Sox has a ton of user parameters that can affect performance, but the Infinite Wave and and Sox web sites say very little about their effect on performance.

The  Sox documentation on the Source Forge web site has a ton of missing graphics, and that does not help.

The Sox documentation is IMO confusing.  I've seen Sox parameter interactions that produce umm, surprising results.

Quote
Surprisingly, the SRC comparison site doesn't seem to have an entry for CEP; perhaps you could make a submission for it (per http://src.infinitewave.ca/faq.html ).


CEP and Audition 2.0 were very similar in terms of performance in most areas including SRC. Audition 2.0 is represented at the Infinite Wave web site, such as it is. AFAIK its so close to CEP 2.1 that there's no need for both results to be published. For 15 year old code, CEP still stands up pretty well. BTW 15 years may be an understatement. This code probably goes back to Cool Edit 95 or earlier.

Hi Rez vs Redbook in Classical music

Reply #49 –
Quote from: UltimateMusicSnob on
My interest in testing is in 44.1/16 **as** 44.1/16, stored in that format and played back as that format, vs. other resolutions (and good MP3 encodings), in **those** formats and played back as those formats. I see the logic of the workaround, but double conversion defeats the purpose as far as I'm concerned.

If the difference is removed in your system by resampling on playback,  then obviously you would use this free real time capability of fb2k. Unless you WANT to hear this unecessary difference.