Itunes and aiif

[KeithL]

Is the above a good method of ripping? At the moment I have a bare bones sb3, but one day I may upgrade to external dac or transporter. I've spent a few hours ripping cds and wonder if I have chosen a suitable format. The ripping is in AIFF at 48000, 16 bit. I don't seem to be able to control the speed of the cdrom drive reading the disc. This varies from 4 x up to 30 x. Is this acceptable? Will I notice the difference between other formats if I do upgrade to a transporter?
Keith

[Ross L]

Perhaps you should try ripping / encoding with several different means you're interested in, then have a listen for yourself?

Before ripping your whole collection maybe just start with a few albums. Which format is best? Up to you to decide...

[EnochLight]

Is this acceptable? Will I notice the difference between other formats if I do upgrade to a transporter?
Keith

If you're even considering getting a Transporter eventually, then for God's sake please rip your music collection into a lossless audio format. I'd say do FLAC, as it's open source, but if you own an iPod then you might try Apple Lossless instead - although it will suck up your iPod's hard drive space.

If you don't own/use an iPod, then go FLAC if you want to actually utilize a $2000 Transporter. Even the highest bitrate setting in AAC is going to lose sound quality somewhat...

[KeithL]

Thanks for the replies. I thought aiff was one of the lossless formats.
Keith

[SteveEast]

Thanks for the replies. I thought aiff was one of the lossless formats.
Keith

It is lossless. The downside is it's also uncompressed. FLAC is generally the choice for compressed lossless on this forum; ALAC if you're using iTunes. Easy enough to convert from AIFF to either FLAC/ALAC without re-ripping.

Steve.

[geraint smith]

Thanks for the replies. I thought aiff was one of the lossless formats.
Keith

Yes, it is: lossless and uncompressed. And yes, iTunes and Aiff are an excellent solution for ripping/storing if you are using a Squeezebox, iTunes and a Mac (and, indeed, an iPod), provided that you are happy with a format that gobbles hard disc space. (I assume, since you are talking about AIFF rather than WAV, that you are running a Mac). You get undegraded sound quality with maximum flexibility and user friendliness. You would also get the sound quality from any of WAV, FLAC or Apple Lossless (ALAC) files, but these formats all have disadvantages for Squeezebox users running iTunes on Macs, especially if they also use an iPod. A summary:

ALAC: 1. Squeezeboxes don't play ALAC, so SlimServer has to transcode it into FLAC or AIFF or WAV as it's playing in order to make sense of it for the Squeezebox. This puts a load on the processing/streaming chain that is not strictly necessary and which some (myself included) think results in lacunae - drop-outs - in the signal over a wireless network. 2. you can't use fast forward or reverse if you are using ALAC. You can using AIFF. 3. It is very much an Apple format, with consequent implications for universal use. Many devices/players including PCs, won't handle it at all (although the same is true to some extent of Aiff).

FLAC is a good format for PC users (provided they don't iPod), but it's a non-starter if you want to use iTunes and a Mac because iTunes doesn't recognise it. Neither does an iPod.

WAV files don't carry tags and will probably end up in an amorphous heap in iTunes, labelled "no album, no artist" - and no use! I've got a bag of them somewhere...

The only disadvantage that I can see of Aiff is that one CD takes about 700Mb, so one would be talking terabytes for a big collection. Still, storage is cheap, and in my view, iTunes and Aiff give the best combination of ease of use, flexibility and sound quality. There are other programmes you can use to rip onto a Mac, but I'm not sure there's any advantage in them except for damaged or otherwise difficult discs. All the ones I've looked at are just ripping programmes. You then have to sort out tags as a separate operation, from what I've seen. That seems a total pain, and I've seen no convincing evidence that they give any better sound quality, or more accurate, or better corrected, copying from CD than does iTunes. (I'd like to, if anyone has some).

The only disadvantage I can see to iTunes - leaving aside debatable claims for other programmes of sonic superiority all else being equal - is that it can handle only a maximum of 48kHz, 16 bit. It cannot rip to 24 bit 196kHz. That may be OK if you're only ripping CDs, but if you're digitising pristine vinyl to tracks for use via a Transporter, which I believe can handle the higher bit/sample rates, you may want something better.

Corrections welcomed if any of this is wrong, of course. (I'd better apologise now for any blunders, I think!)

[Eric Seaberg]

The ripping is in AIFF at 48000, 16 bit. I don't seem to be able to control the speed of the cdrom drive reading the disc. This varies from 4 x up to 30 x.
Keith

It SHOULD be at a sample rate of 44.1kHz, not 48kHz!! Also, the reason the speed varies is because of the disc actually changing speed as it goes. The 'inside' of the disc spins much faster than the 'outside' of the disc for the same amount of throughput.

As someone has already mentioned, AIFF is a RAW file format and not lossless in the same way as ALAC or FLAC are. You will save some HD space by using ALAC, especially if you're using iTunes to rip. My biggest problem with FLAC, at least as a Mac user, is it's not as easy to edit the TAG information. That's pretty simple in iTunes if you stick with ALAC.

[KeithL]

Thanks Geraint & Eric for your most informative posts.
It seems I have stumbled on the most suitable format for my present needs. I want the highest quality available when ripping from cd. So, Eric, do I set the itunes aiff ripping preference to 44000 instead of 48000? Another question... can slim server seamlessly span different disc drives, ie. if I had two or three external drives?
Keith

[Eric Seaberg]

Keith, there shouldn't be a setting in iTunes to change the ripping sample rate! ALL audio CDs are 44.1kHz!!! Only video (DVD, etc) are 48kHz... that's the 'standard'.

DO NOT confuse BITRATE with SAMPLE RATE!! The settings for AIF encoding should be set to AUTOMATIC. Let it do what it THINKS it should do. DO NOT CUSTOMIZE to a higher sample rate as it will totally screw up your chances to re-burn to an Audio CD, if you ever want to do that.

Otherwise, go to APPLE LOSSLESS as it will retain the quality while saving some HD space. Make SURE you've got "USE ERROR CORRECTION WHEN READING AUDIO CDs" checked in ALL instances of ripping, as this will make sure you're grabbing all of the data where scratches/fingerprints/mustard have been smeared on the CD surface. It may take a little longer, but you're chances of a good rip are improved considerably.

[geraint smith]

Keith, there shouldn't be a setting in iTunes to change the ripping sample rate! ALL audio CDs are 44.1kHz!!! Only video (DVD, etc) are 48kHz... that's the 'standard'.

DO NOT confuse BITRATE with SAMPLE RATE!! The settings for AIF encoding should be set to AUTOMATIC. Let it do what it THINKS it should do. DO NOT CUSTOMIZE to a higher sample rate as it will totally screw up your chances to re-burn to an Audio CD, if you ever want to do that.

Otherwise, go to APPLE LOSSLESS as it will retain the quality while saving some HD space. Make SURE you've got "USE ERROR CORRECTION WHEN READING AUDIO CDs" checked in ALL instances of ripping, as this will make sure you're grabbing all of the data where scratches/fingerprints/mustard have been smeared on the CD surface. It may take a little longer, but you're chances of a good rip are improved considerably.

er....I hate to contradict Eric, but there is in fact an option in iTunes to sample at either 48kHz or 44.1kHz (in the "Preferences - importing - custom" menu).

I leave it at 44.1kHz, myself. There's some debate about whether sampling at the higher rate will do anything for ripping CDs of which, as Eric says, the standard rate is 44.1. In any case, it used to be true (pre-Transporter) that no Slim Device could handle this, I think, but I believe that that has now changed. Really, it is a matter of preference - as Ross said to you right at the start, suck it and see. I can myself hear no advantage in oversampling to 48kHz when ripping CDs. However, when transfering from vinyl, it sounds better to me if I use the higher sample rate throughout the chain of capture/digitisation (although I may be imagining this. I've not double blind tested it), and the higher the rate, the better I think it sounds all the way up to 192kHz - better than CD, in fact. In any case, it is easy to convert back down to 44.1kHz if you do want to burn a CD. Bitrate is indeed automatic, and will be 1411kbps at 44.1kHz sample rate. (It's higher if you do choose 48kHz).

Incidentally, iTunes will perfectly happily handle and play files with sample rates up to at least 96kHz (I pick that one because I've just found one at that rate in my library) if you can get another programme to sample at that rate. It just won't rip at anything above 48kHz itself - probably just as well, because if you think 44.1kHz/1411kbps eats disc space, you should see the size of a file at 96kHz sample rate and the accompanying bit rate of 3072kbps!

[Eric Seaberg]

er....I hate to contradict Eric, but there is in fact an option in iTunes to sample at either 48kHz or 44.1kHz (in the "Preferences - importing - custom" menu).

I leave it at 44.1kHz, myself. There's some debate about whether sampling at the higher rate will do anything for ripping CDs

I do know there's an OPTION to rip at 48kHz, but you're wasting bandwidth! Since the original was at 44.1kHz and has a 'brick-wall' filter at 20kHz, there's NO reason to re-sample (rip) at anything other than the original 44.1kHz... THERE'S NOTHING THERE!! You're just making the file LARGER for no reason (please excuse the CAPS, but I'm hoping it makes a point).

I'd guess that Apple gave you the option IF anyone ever came up with a way to rip HIGHER SR material down to 48kHz, i.e. 96k or 192k DVD-A, etc.

As far as transferring from vinyl, if you're planning on putting the final product on CD, you're still better off recording at 44.1k or 88.2k. If your record at 48k then SRC down to 44.1k, the math involved is not as easy to accomplish as if going from 88.2 to 44.1. Of course this also depends on whose SRC you're using.

I still offer the best option of keeping it at 44.1kHz if that's your final product, yet record at 24-bit whenever possible.


I've been in the mastering/recording business since 1971 and have tried and tested it all. TRUST ME!! Taking an original 44.1k recording up to 48k/88.2k/96k/176.4k/192k does NOTHING except make your file L-A-R-G-E-R!!! You gain NOTHING because there's nothing to get back. However, if you're planning on editing the original file at all, then get it to 24-bit before you start. Even if there's no data there, every time you change the file you're getting as close back to the original 'number' as possible.

[geraint smith]

I do know there's an OPTION to rip at 48kHz, but you're wasting bandwidth!

Sorry! I misunderstood you. I thought you were being puzzled - ie "there shouldn't be an option" meaning "what's this about an option? Where are you seeing it? There shouldn't be one there" because that's the way I'd probably have phrased it myself (to be gentle!) but in fact you were saying "this option is silly because there's no point in it and it should not be there". Which is fair enough. A little touch of ambiguity in the night!

Since the original was at 44.1kHz and has a 'brick-wall' filter at 20kHz, there's NO reason to re-sample (rip) at anything other than the original 44.1kHz... THERE'S NOTHING THERE!! You're just making the file LARGER for no reason (please excuse the CAPS, but I'm hoping it makes a point).

There's no need to shout, you know! I know very well already that this is all perfectly correct. However, I thought when I wrote that I remembered seeing some debate about the matter somewhere recently and thought I'd better mention it even if it doesn't make sense (and even if I certainly can't tell the difference and don't quite see how, logically, anyone could.)

.......As far as transferring from vinyl, if you're planning on putting the final product on CD, you're still better off recording at 44.1k or 88.2k. If your record at 48k then SRC down to 44.1k, the math involved is not as easy to accomplish as if going from 88.2 to 44.1. Of course this also depends on whose SRC you're using.

I still offer the best option of keeping it at 44.1kHz if that's your final product, yet record at 24-bit whenever possible.

Yes, of course this is true if one wants to record to CD subsequently, but if the main use of the material is to put it through a sound card (or external DAC - or a Squeezebox?) then, and again correct me if I'm wrong, isn't 48kHz actually quite a good thing because many sound cards surreptitiously work on that rate? And yes, as far as I'm concerned it's iTunes' inability to rip at 24 bit that is its biggest drawback.

I've been in the mastering/recording business since 1971 and have tried and tested it all. TRUST ME!!

Well, you know, I did absolutely until that moment, but now you've really me suspicious. Now I'm thinking: so what have you got to hide, and when's the sucker punch coming?

Geraint.

PS. Do I need to add this?

;^)

[mmcguff]

One mild warning about ripping to aiff files: There seems to be some sort of issue in more recent versions of Slimserver with not reading all the tag information correctly (for me, at least). If I have "use iTunes" turned off, Slimserver seems to only sporadically pick up certain tag fields (disk #, composer, occasionally even some more common fields), sometimes doing different things for different tracks of the same CD. It DOES seem to work properly if I have "use iTunes" turned on, but then it isn't really reading track info from the files, but from your iTunes XML file. (Why would you want to set "use iTunes" off? Well, for example, I don't want my audiobooks to show up in Slimserver, so I keep them in a separate directory and just have Slimserver scan the music folder. I wish I knew a different way to exclude a genre from Slimserver without affecting iTunes...)

I did try to bring this up with Slimdevices tech support, but was told that Slimserver didn't support tags in aiff files and they were just like wav files, where it tries to figure out the info from directory structure. This clearly is not the case (otherwise how could it pick up composer info for at least SOME tracks?), but the person I was emailing lost interest when I found that setting "use iTunes" on would take care of things, so I doubt anybody is actually looking into the intermittent way tag info is read.

I have heard rumors that the next version of OS X (Leopard) might support FLAC files natively. If that DOES turn out to be true, then I will be converting everything over to FLAC's, but for the time being aiff's seem a decent choice, if you have the disk space.

[Eric Seaberg]

isn't 48kHz actually quite a good thing because many sound cards surreptitiously work on that rate? And yes, as far as I'm concerned it's iTunes' inability to rip at 24 bit that is its biggest drawback.

IMHO, the fact that iTunes can't rip from a 16-bit source to a 24-file file isn't really a drwaback... those last 8-bits would be ZEROs and just take up space. Especially if you're going to transcode to a different format, it really doesn't make sense.

48kHz is marginally better than 44.1kHz, but was really developed to use with VIDEO. All video source material has an audio SR of 48kHz (or 96kHz or 192kHz). There's still a brickwall at 20kHz in most D/A filters (obviously only at 48kHz).

As mmcguff has mentioned above, AIFF files do not have room for a lot of metadata within the file for TAGS and such. Recording studios and Production facilities are moving to BWF (Broadcast Wave File) as the new 'standard' format due to its ability to store large amounts of metadata. I'd LOVE it if FLAC was a new format for OS 10.5 but would be surprised since Apple spent so much effort on their own lossless codec. Still...