Jump to content
IGNORED

iTunes lossy cd ripping to ALAC?


qwfqh

Recommended Posts

I would like to share an unexpected finding about iTunes CD ripping: any comments, scrutiny, verification and – ultimately – confirmation or disproval are very welcome. My setup is as follows:

 

Windows 7

iTunes 11.2.2.3

dBpoweramp reference 15.1

Audacity 2.0.2

 

I tested track 1 of the CD described here (Release) – a solo harpsichord track very rich in high frequency harmonics.

 

Findings

Ripping with iTunes to lossless ALAC resulted in files approximately 10% smaller than ripping to the same lossless format with dBpoweramp. To find out what was going on I ripped the same track again to flac with dBpoweramp and checked that dBpoweramp ripped consistently to the same waveform, as one would expect, either using ALAC or flac formats. I then converted both the iTunes-ripped file and the dBpoweram-ripped one to wav (with dBpoweramp) and took a look at the waveforms using Audacity: the spectra (of the first 237 seconds) matched closely below 3000 Hz, but were visibly different above that threshold, with the spectrum of the ‘lossless’ waveform ripped via iTunes fainter and fainter at higher frequencies (the gap at 7000 Hz was of the order of 10 db).

 

Comment

If confirmed, this would set a huge disappointment for the quality and reliability of iTunes. While it is hoped that the losses incurred by the signal, as processed by iTunes, are based on a perceptual model and might therefore be barely audible in most practical circumstances, it would be beyond any excuses, or acceptance, that a procedure that iTunes clearly, openly and unmistakably marks as ‘lossless’, turns out as a matter of fact to be less than that.

 

 

Thanks in advance for your comments

flac spectrum from dBpoweramp.png

alac spectrum from iTunes.png

Link to comment

I've never ripped with iTunes on Windows, but have on OS X and compared the rips to those produced by XLD, which in addition to producing a rip consistent with iTunes, produced a rip consistent with the database it consults.

 

Since you converted both files to wav, they should have identical sha1 and md5sum checksums. Do they (I assume not, based on what you describe). You might also have to adjust for pre-gap, which conceivably could cause the difference in the appearance of the two spectra, since they take a time slice and project it onto a single plot. If one was offset slightly relative to the other, you wouldn't be comparing like to like.

 

I really hope it is one of those things, because otherwise this is a really disturbing finding. Thanks for posting.

Link to comment

The checksums, of necessity, do not match. Both wav files tested begin with 4 seconds of silence, followed by the sharp attack of bach's chromatic fantasy. Anyway, even if there was a small time gap, my understanding is that time shifting does not affect the power spectrum of a given signal; in our case the length of the analyzed waveform is fixed (about 4 miuntes from start), and a pre-gap would indeed exclude a chunk of trailing sound from the sample with the longest initial pause, so the signals would not, indeed, match exactly - but a fraction of a second, or even a few seconds, should be of almost no consequence on the spectrum of a 4 miuntes sample. Thanks for your reply

Link to comment
I would like to share an unexpected finding about iTunes CD ripping: any comments, scrutiny, verification and – ultimately – confirmation or disproval are very welcome. My setup is as follows:

 

Windows 7

iTunes 11.2.2.3

dBpoweramp reference 15.1

Audacity 2.0.2

 

I tested track 1 of the CD described here (Release) – a solo harpsichord track very rich in high frequency harmonics.

 

Findings

Ripping with iTunes to lossless ALAC resulted in files approximately 10% smaller than ripping to the same lossless format with dBpoweramp. To find out what was going on I ripped the same track again to flac with dBpoweramp and checked that dBpoweramp ripped consistently to the same waveform, as one would expect, either using ALAC or flac formats. I then converted both the iTunes-ripped file and the dBpoweram-ripped one to wav (with dBpoweramp) and took a look at the waveforms using Audacity: the spectra (of the first 237 seconds) matched closely below 3000 Hz, but were visibly different above that threshold, with the spectrum of the ‘lossless’ waveform ripped via iTunes fainter and fainter at higher frequencies (the gap at 7000 Hz was of the order of 10 db).

 

Comment

If confirmed, this would set a huge disappointment for the quality and reliability of iTunes. While it is hoped that the losses incurred by the signal, as processed by iTunes, are based on a perceptual model and might therefore be barely audible in most practical circumstances, it would be beyond any excuses, or acceptance, that a procedure that iTunes clearly, openly and unmistakably marks as ‘lossless’, turns out as a matter of fact to be less than that.

 

 

Thanks in advance for your comments

 

Well, it's certainly not a universal issue:

 

Screen Shot 2014-08-05 at 10.45.24 AM.png

 

That is the first track of "Carmina Burana" (London Symphony Orchestra / Previn), as ripped by iTunes (12 beta) and dBpoweramp (1.0 beta 6) on my MacBook Pro, viewed in Audacity 2.0.5. Identical (at least to my naked eye).

 

Will be interested to see if any other users report variances on Windows.

John Walker - IT Executive

Headphone - SonicTransporter i9 running Roon Server > Netgear Orbi > Blue Jeans Cable Ethernet > mRendu Roon endpoint > Topping D90 > Topping A90d > Dan Clark Expanse / HiFiMan H6SE v2 / HiFiman Arya Stealth

Home Theater / Music -SonicTransporter i9 running Roon Server > Netgear Orbi > Blue Jeans Cable HDMI > Denon X3700h > Anthem Amp for front channels > Revel F208-based 5.2.4 Atmos speaker system

Link to comment
Well, it's certainly not a universal issue:

 

[ATTACH=CONFIG]13969[/ATTACH]

 

That is the first track of "Carmina Burana" (London Symphony Orchestra / Previn), as ripped by iTunes (12 beta) and dBpoweramp (1.0 beta 6) on my MacBook Pro, viewed in Audacity 2.0.5. Identical (at least to my naked eye).

 

Will be interested to see if any other users report variances on Windows.

 

 

Thanks for taking your time to have a look at it. Your post prompted me for some further testing, with perplexing results.

As a precaution, I disinstalled and then reinstalled both itunes and audacity to their respective latest version; then, I tested:

 

 

  • yet again my original track, that revealed the same difference in high frequency spectra
  • a piano track and two other harpsichord tracks, that produced upon ripping with either itunes or dbpoweramp undiscernible specrta. However, none of the tracks I had at hand, even the harpsichord ones, went near to fill the high frequency spectrum up to the audible limit with a non-zero signal, as does the original track

 

My best guess is that itunes, upon detection of a long tailed spectrum on the side of high frequencies, performs silently some kind of smooth cutoff, with the well meaning intention to suppress noise, thus filtering frequencies above 7000 Hz.

 

So the whole matter seems of less concern than it appeared at fist sight - indeed, anything but a very subtle effect wouldn't have been spotted long ago... I keep wondering if others can actually reproduce this finding. And, of course, can't help feeling a bit uneasy about what other well meaning tweaks do happen under the clear, clean and perfectly burnished surface of itunes.

 

Thanks again for your reply

Link to comment

Audacity doesn't use the whole four minutes or whatever to create the power spectrum. It uses a much thinner wedge. If the two wedges are not identical, the power spectrum will not be identical.

 

I doubt iTunes is making any changes, well-meaning or otherwise. Without access to the CD, Windows, and the relevant software, I can only speculate, but I suspect this is user error (differing offsets the two programs apply by default could easily give trivial differences). While you are using Audacity, why not make an FFT plot of each and compare those? Pattern differences independent of time displacement will be much easier to see.

Link to comment
Thanks for taking your time to have a look at it. Your post prompted me for some further testing, with perplexing results.

Can you take the dbPowerAmp track, convert it to ALAC using iTunes and compare this to the original rip. If there is anything happening with the ALAC conversion it will probably happen when converting.

 

Oh you should also try to reinstall dbPowerAmp - perhaps its THAT which is causing the problem (on your system) rather than iTunes!

 

Eloise

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

iTunes does not perform Secure Ripping, so I would never use it to rip my CDs.

The "error correction" option is mostly worthless.

 

When properly configured for secure ripping, dBpoweramp will guarantee that you have a 1:1 copy of exactly what is on the disc.

 

 

One thing that iTunes does, which most programs do not, is that it is aware of CD pre-emphasis and will apply a de-emphasis filter to rips automatically - and that seems to be what is happening here.

 

You can easily apply a de-emphasis filter to affected tracks using SoX, which will convert the track to a 24-bit file in the process to preserve audio quality, but this is something that must be done manually.

 

I'm not sure that dBpoweramp is even aware of pre-emphasis and has a way to inform the user.

However, pre-emphasis is extremely rare, and mostly only applies to a short list of very early CDs - I think I only have two discs in my entire collection which use pre-emphasis.

Link to comment

Thanks to you all for your interest!

 

 

I was in no way aware that pre-emphasis had at some point in time crossed the boundaries of the analog world to take a hold into digital audio, thanks Skeptic for resolving the issue. As it seems, thumbs up for itunes and shame to dbpoweramp for not dealing properly with pre-emphasis on old CDs...

 

 

Here are a few more comments:

- the problem is in ripping, not in ALAC conversion - I converted the dbpoweramp-ripped track to ALAC via itunes, and found that the signal exactly matches the original; in fact, the file size of the resulting .m4a file was 37 Mb, contrasted with 33 Mb for the .m4a file obtained by directly ripping the track with itunes

- I am fairly confident, and would like to reassure anyone in doubt, that the audacity spectrum analyzer does what one expects from it: the signal is subdivided into chunks of the specified size, an FFT is computed for each chunck, and the spectra of all chunks are averaged to yield a reliable estimate of the spectrum of the entire signal. This said, and sticking to the principle that trust must be earned, my very first sanity check before posting (actually, even before computing the spectra), was to have a look at the two signals at the point when the first note is struck, and realized that they _do_, in fact, differ (see attached screenshots)

 

 

Thanks again for being patient and kind to a newbie in this forum

 

 

waveform2.png

waveform1.png

Link to comment

No idea how accurate it is ... But there is a list of CDs with pre-emphasis here -- Pre-emphasis (release list) - cdHistory

Eloise

---

...in my opinion / experience...

While I agree "Everything may matter" working out what actually affects the sound is a trickier thing.

And I agree "Trust your ears" but equally don't allow them to fool you - trust them with a bit of skepticism.

keep your mind open... But mind your brain doesn't fall out.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...