Looking for Advice on Ripping my CD Collection (1 Viewer)

[jcroy]

All a FLAC file is is a compressed WAV file. EAC does those with ease so if your car plays them you could avoid the whole compression part completely and not have to double encode/convert.

I've watched the folder when a disc is ripped. EAC rips it to a WAV file and then converts, or rather compresses, it to FLAC.

WAV is an uncompressed audio format. FLAC is a lossless container format that can be used to compress and decompress (zip and unzip) another format like WAV. But they're not related to each other like you're suggesting. FLAC can be used to compress AIFF, for example.

How EAC works depends on how you have it set up. I use it to rip WAV and don't use FLAC at all.

For amusement, I decided to see how "lossless" *.flac really is.

I took some *.wav files I haven't deleted yet, and using VLC converted them in a round trip chain of:

wav (original) -> flac -> wav (second)

Comparing the data of the original and second wav files to see how much they differ, the obvious differences were in the wav file headers and the length of the padding (ie. zeros) at the end of the wav file.

So using a hex editor, I deleted the headers and tail end padding zeros from both wav files, so that what is left over are the respective core music data. (ie. This was the only way to make an apples-to-apples comparison).

Running sha256 hashes on these two hex edited wav files, showed that the core music data was identical in both respective files.


I'm guessing this is what is meant by "lossless", where the original *.wav core music data can be faithfully replicated exactly in a wav -> flac -> wav conversion chain.

 

[BobO'Link]

I'm guessing this is what is meant by "lossless", where the original *.wav core music data can be faithfully replicated exactly in a wav -> flac -> wav conversion chain.

Yes, that's exactly what's meant by lossless, no matter which file conversion method is used. It's why I rip to FLAC and convert to MP3 only if needed. The FLAC files would allow me to create an exact duplicate of the original disc if needed.

While, unlike Mike, I don't "need" FLAC in the car, that's just one use for the files with the primary purpose being archiving/backup. That my car player will play FLAC just makes the process easier in my case.

 

[jcroy]

Looking more closely at the *.wav file specifiction, the header differences I saw corespond exactly to the file size differences. (One wav file had additional zeros padding at the tail end of the file).

https://www.topherlee.com/software/pcm-tut-wavformat.html

Wave File Specifications

In particular bytes 5 to 8, and bytes 41 to 44. (These correspond to hardcoded file size).

 

[jcroy]

Looking more closely at the FLAC header spec and looking at the *.flac file I produced in this wav (original) -> flac -> wav (second) round trip chain via VLC, a hex dump of this *.flac file reveals that VLC is encoding wav -> flac data in 4608 bytes sized blocks.

Free Lossless Audio Codec

This document defines FLAC, which stands for Free Lossless Audio Codec, a free, open source codec for lossless audio compression and decompression.

tools.ietf.org

FLAC - format

A free, open source codec for lossless audio compression and decompression

xiph.org

For the second wav file produced in this chain flac -> wav (second) from the intermediate flac file, the size of the music data is consistent with a 4608 bytes size block. (ie. The size of the second wav file's music data segment with the header removed, is exactly an integer multiple of 4608 bytes).

 

[jcroy]

Recently I purchased an audiobook which turned out to consist of over a dozen audio cd discs (ie. standard redbook audio cd at 44.1 kHz 16 bits).

Ripping all these dozen+ audio cd discs to the computer, the size of the *.wav files in total was around 10 gigabytes.

I converted them into *.flac files, where the size of the sum total of all dozen+ corresponding flac files was slightly less than 2.5 gigabytes.

Essentially a 4:1 compression ratio for audio which was talking with no music. (I don't usually get ratios this efficient, when coverting music wav -> flac).

 

[Steve Chomicz]

both record 0 Hz to 655,000 Hz way beyond our 20K Hz for those with good hearing.

wav takes more space for it rips everything including the no sound areas increasing file size. File size does not equal music quality. Wav is not well suited to adding metadata as it is intended to record the sound file. FLAC is a zip container that omits the no sound areas for there is no sound there so you don't lose anything. It results in smaller file size and allows metadata. But it takes a tiny bit more of CPU time to unzip to play. The sound file extracted is identical to the wav file.

The real villain is iTunes. It doesn't support FLAC files because they want you to use Apple Lossless (ALAC) which is not as good as WAV or FLAC.

And the real audiophile issue is vehicle audio, which is as far from a concert hall as you can get. Speaker placement in cars by their designers is a challenging compromise that few appreciate. Even with the now dead car CD player the variable road noise, car vibration, driver's focus, kid's screaming, spouses talking, navigation AI speaking, all result in diminished ability to appreciate the nuances of CD quality playback from a wav or flac file.

the single most important factor in vehicle audio playback is to turn off all the audio enhancement options and select stereo. Yes, good old fashion stereo as the sound field. The improvement in sound quality will be amazing. After all, once the Beatles changed from recording in mono to recording in stereo all music followed suite. Car audio systems take the sound file and surround sound it changing the way it was intended to be heard.

Lastly, the single most human factor is you. What sounds the best to you it the right way to go.

Having an archive in WAV or FLAC is the way to go for storage purposes. What type of sound file you listen to should depend on where you are listening and with what devices and speakers or headphones you are using.

My advice, take the easiest route as long as it sounds good to your ears. and do it with a blind test.

Peace

 

[Guardyan]

I'm embarking on a similar project. So this thread has been very illuminating. Though I'm not ripping stuff to play just in my car, I'm trying to "future proof" some CDs.

[...] every now and then I have to deal with the names not matching up exactly, or being wrong. But it was worth it just from a space issue.

[...]

Why? Because Gracenote and the like having entries that are wrong? Or because of some error during the ripping?

EAC is popular because of its accuracy, but with that comes the issue of time commitment. It has different Extraction Methods, which can vary the length of time it takes to rip each disc. You can use it in Burst mode, which is probably as fast as a quick rip in iTunes, or you can use Secure mode which takes longer. Secure goes over a disc twice to ensure it's ripped accurately. Burst doesn't do any error correction (I believe). Since you have hundreds of discs, you may want to determine which approach is best for you. Or maybe prioritizing your titles to use both methods would work.

Also, just as general workflow advice (since I haven't seen it put this way).... don't keep MP3s or other lossy files ONLY. If you're taking this time, save your rips as uncompressed or lossless files. Even if you use MP3s for regular listening, rip in WAV or FLAC for archival purposes. Create MP3s from those if you want.

Why is EAC a better option than iTunes? (Seems to be a popular opinion around here).

iTunes also checks for ripping mistakes I think. Is this a PC VS Mac thing or is EAC indeed much better than iTunes?

iTunes is probably the gold standard, or close to it, for the organization – but it may not be the gold standard for extracting bit-perfect audio from the CDs themselves.

In another forum, there was someone claiming that iTunes often did not extract audio in bit-perfect ways - and that it was easy to tell by extracting the same songs twice, and comparing the output files. His preferred solution was to extract audio using some other application that extracted audio over and over again, until it got two copies that were identical.

Hmm... considering that I have already converted the same CD more than once with iTunes just to compare audio files, and just once I was able to find some differences between rippings of the same CD, can you please explain why would that app that extracts audio over and over be a better option? If iTunes gave me identical copies during my project, would that be approved by that person in the other forum? I mean... I know you don't live in his mind so you could never answer for him, but I'm curious about your perspective since you seem to value his advice/views. Also, how long ago was that? Because iTunes has certainly improved ever since its early days, right?

This is also true for JRiver Media Center. It's a program that is similar to iTunes but much more user-friendly. It's PC/Mac compatible. Just like you, I frequently edit Metadata that's "off". BTW, I've owned this program for five or six years now and haven't looked back to iTunes.

What is it that makes iTunes not that user-friendly when compared to JRiver Media Center in your opinion?

EAC puts all the tracks into the folder you specify. If you don't change it, it all goes into a single folder.

I have a folder for the artist and under that a folder for each album and for multi-disc albums a folder under the album title for each disc. I rip to the folder where I want the tracks to live when done.

I rip to FLAC because it's "lossless," takes less storage space (I have over 600GB of files), and supports "gapless" playback. I can use those FLAC files to recreate the original disc exactly. MP3 files can *not* be played back "gapless" in any device I've tested. IMHO, that alone makes MP3 compression pretty worthless (I have lots of albums where one song segues into another and MP3 breaks that smooth transition with at least a 1 second gap). I do not convert to MP3 because all my devices support FLAC files, even a ~10yo portable player.

I also do not use those ripped files for anything other than backups, car playback, and occasional portable playback. If I'm at home I play the CD directly. That means the artist/album/disc folder structure works great because I can easily find what I want to put on a USB drive for the car (I currently use a 128GB drive for stuff I know I always want in the car and smaller drives for temporary stuff). I update those "temporary" use drives every 4-8 weeks (depends on if I've purchased anything new - it goes on the temp drives unless I decide, after a few listens, I want it all the time).

The few times I play things back from the computer it's with VLC as it supports audio and video playback. I don't need, nor want, a local "database" program like iTunes or Windows Media Center getting in the way. If those files get mis-tagged it's usually because I didn't double check them before ripping. EAC lets me put *any* cover I want on the files so if it offers the "wrong" one or one I don't like/own I can look it up anywhere and drop it into EAC easily. Should I miss some song tag information or get them wrong it's easy to re-rip with the correct information or just use a separate tag editor.

If you want, I'll post what I use for the song string (basically just the track # and name). I don't include any album information in the track name and prefer it to be short and sweet letting my folder organization tell me the artist/album. From what I've seen, those having all of that in the name are typically done for "database" programs that rip/dump everything into a single folder with no organization outside that front end program.

Even my car system, which I feel is rather rudimentary for a 2017 system (mainly due to its inability to play files gapless - even WAV), can sort my files by artist, name, album, etc. as it's using the tags, or imbedded text info (don't know which for sure - don't really care as it works), for that process.

I don't understand the "gapless" playback dilemma, because I have several MP3s that I can play gapless on my phone, my old iPod, my home audio system. Are you sure that when you created those mp3s you used to test with different devices, you selected the import options that requested audio files to be converted just as they were in the CD?

MP3 files can in fact be played back gapless. The iPod Nano players we have owned support this, as do the apps on my Android smartphone. Since iPods support this, I would expect an iPhone to do the same (don't own one, so cannot verify). I am not sure about the players in our GM vehicles, since we just put those on random play.

Yup. Pretty much my experience. I was able to play MP3 files gapless on the most different devices.

For MP3 files, I would use 320kb/s constant bit rate or 256kb/s variable bit rate. Anything lower is garbage, IMHO. Mike said he has a copy of Adobe Audition. It can export MP3 in those quality levels. It also has AAC export capability, but as MPEG-2 audio. Not M4A. You can choose a variety of bit rate levels for AAC files. The default is 128 kb/s, but you can choose 160, 192, 576, 768, 960 and 1.15 Mb/s. I don't know why 256 kb/s isn't available as an option.

What would be the "audio sin" of converting an MP3 file using 320kb/s VBR? I've researched that before and it seems like that a lot of websites recommended CBR only if one was restricted to old hardware and that VBR was much more efficient in relation to quality/file size. Would a 320kb/s VBR file be defeating the purpose of using 320 instead of 256kb/s? Could you please explain that a little better to me? I had been using VBR and now I feel like a bit of a fool although music I love have been backed up in AIFF.

[...]

The real villain is iTunes. It doesn't support FLAC files because they want you to use Apple Lossless (ALAC) which is not as good as WAV or FLAC.

[...]

There seems to be a lot of different opinions on the matter though. Many say that FLAC and ALAC are both great and it all boils down to the system you are "tied to." Some articles claim ALAC is much better.

Also, isn't AIFF just as good as WAV? So it's also a good option to use when archiving and storing, right?

 

[Thomas Newton]

Why? Because Gracenote and the like having entries that are wrong? Or because of some error during the ripping?

I don't believe that Gracenote / CDDB / etc. have anything to do with actual audio extraction – just with matching of a set of songs to the corresponding album and song names. I let iTunes retrieve names from the Internet – but I also give the information a quick once-over.

Why is EAC a better option than iTunes? (Seems to be a popular opinion around here).

iTunes also checks for ripping mistakes I think. Is this a PC VS Mac thing or is EAC indeed much better than iTunes?

I don't believe it would be a PC vs Mac thing – more an application (EAC) vs. application (iTunes / Music) one, that has PC vs. Mac overtones only because iTunes / Music is bundled with Macs (and therefore very widely used).

iTunes has a preference setting to "Use error correction when reading Audio CDs". A note in the dialog indicates that using this setting can reduce import speed. For now, I am using iTunes to import CDs, but I am also importing CDs with this setting selected.

Hmm... considering that I have already converted the same CD more than once with iTunes just to compare audio files, and just once I was able to find some differences between rippings of the same CD, can you please explain why would that app that extracts audio over and over be a better option? If iTunes gave me identical copies during my project, would that be approved by that person in the other forum? I mean... I know you don't live in his mind so you could never answer for him, but I'm curious about your perspective since you seem to value his advice/views. Also, how long ago was that? Because iTunes has certainly improved ever since its early days, right?

Keep in mind that CD-Audio error detection and correction is not as thorough as CD-ROM, DVD-ROM, or DVD-Video error detection and correction.

If you get the same results twice in a row, that's not absolute proof that there were no read errors. It might just indicate that the drive ran into uncorrectable errors both times, and made up the same intermediate data both times, in the hopes that the data would be sufficient to fool the average human listener.

 

[Mike Frezon]

Is there anyone here who has used a Brennan B2 unit for this task?

I'd love to hear your opinions on it.

 

[Scott Merryfield]

Why is EAC a better option than iTunes? (Seems to be a popular opinion around here).

iTunes also checks for ripping mistakes I think. Is this a PC VS Mac thing or is EAC indeed much better than iTunes?

It's not a Mac versus PC thing. Exact Audio Copy can use an external compression program, and the LAME MP3 external encoder is generally considered better than iTunes at encoding MP3s. However, at higher bit rates it's debatable if you will be able to tell the difference. I have used iTunes on my Windows PC (I'm not a Mac user) at times to rip / encode CDs, and at higher bit rates the resulting MP3s sound fine to me. Most of my collection is ripped and encoded via EAC + LAME, though.

 

[jcroy]

I don't believe that Gracenote / CDDB / etc. have anything to do with actual audio extraction – just with matching of a set of songs to the corresponding album and song names. I let iTunes retrieve names from the Internet – but I also give the information a quick once-over.



I don't believe it would be a PC vs Mac thing – more an application (EAC) vs. application (iTunes / Music) one, that has PC vs. Mac overtones only because iTunes / Music is bundled with Macs (and therefore very widely used).

iTunes has a preference setting to "Use error correction when reading Audio CDs". A note in the dialog indicates that using this setting can reduce import speed. For now, I am using iTunes to import CDs, but I am also importing CDs with this setting selected.




Keep in mind that CD-Audio error detection and correction is not as thorough as CD-ROM, DVD-ROM, or DVD-Video error detection and correction.

It basically boils down to how hardcore you are about absolute data accuracy, when ripping redbook audio cds. If you're dealing with audio cds which are not damaged/defective/rotting, the main problem will be jitter and compounded with how a cdrom drive's cache system functions..

CD Ripping Terminology - LinnDocs

docs.linn.co.uk

CD ripper - Wikipedia

en.wikipedia.org

Primarily read offset jitter from seeking.

If you get the same results twice in a row, that's not absolute proof that there were no read errors. It might just indicate that the drive ran into uncorrectable errors both times, and made up the same intermediate data both times, in the hopes that the data would be sufficient to fool the average human listener.

This is actually the bane of some cdrom drives, where there is no easy standard way to "flush" the cache. So if a particular audio cd sector is read a second time, the cdrom drive will just get that "sector read" from the cache and NOT from re-reading the actual audio cd disc.

Some cd ripper programs had all kinds of algorithms which figured out ways to deliberately trick the cdrom drive into re-reading a sector from the actual audio cd disc, and not from the cache.

(Older cdrom drives did not have a standard "force unit access" command to re-read a redbook audio cd disc).

 

[jcroy]

If you're the type of person who is extremely paranoid about demanding absolute data accuracy, the only other option I can think of is to write your computer code. You can start off by looking at the source codes for open source cd ripper programs like cdda2wav or cdparanoia.

cdrtools/cdda2wav at master · Distrotech/cdrtools

http://cdrecord.berlios.de/private/cdrecord.html. Contribute to Distrotech/cdrtools development by creating an account on GitHub.

github.com

CDDA Paranoia Download

GitHub - opus47/cdparanoia: Fork of xiph.org cdparanoia. Provides JSON based reporting for upstream tools.

Fork of xiph.org cdparanoia. Provides JSON based reporting for upstream tools. - opus47/cdparanoia

github.com

 

[Mike Frezon]

Is there anyone here who has used a Brennan B2 unit for this task?

I'd love to hear your opinions on it.

I am giving this some serious thought:

 

[Jason Goodmanson]

Why? Because Gracenote and the like having entries that are wrong? Or because of some error during the ripping?

Every now and then iTunes will have typos in the name that it grabs, or more rarely, it grabs a foreign language for the titles. Or I just don't like how it titles songs.

iTunes just makes it easy for me - I'm still a PC guy, but I have an iPod, iPhone, iPad, and AppleTV and I love how everything talks to each other.

I have more than enough space on all of my devices so if I want a certain set of music in the car (ApplePlay FTW!) I just add it to my phone and it's all good.

Everything I rip is encoded as Apple Lossless and I can't tell any difference. My 101-CD changer hasn't been connected to my AVR is probably 15 years.

 

[jcroy]

My 101-CD changer hasn't been connected to my AVR is probably 15 years.

(On a tangent).

Heh. Is this one of the pioneer models?

Back in the day, I always wanted one of those giant cd changers, but never got around to buying one.

 

[Jason Goodmanson]

(On a tangent).

Heh. Is this one of the pioneer models?

Back in the day, I always wanted one of those giant cd changers, but never got around to buying one.

Definitely is! I forget how long I've had it - I do remember wishing years later that I got one of the 100 (maybe 50?) CD/DVD changers.

I know I loved the heck out of my 6-disc Pioneer changer (with the weird cartridges) but don't know if I ever really used the 100 disc version.

 

[Guardyan]

I don't believe that Gracenote / CDDB / etc. have anything to do with actual audio extraction – just with matching of a set of songs to the corresponding album and song names. I let iTunes retrieve names from the Internet – but I also give the information a quick once-over.

Yes, it doesn't have anything to do with the actual extraction. I was just double checking with Jason that the problem he had with some titles was a database thing and not an issue with Apple's software.

I don't believe it would be a PC vs Mac thing – more an application (EAC) vs. application (iTunes / Music) one, that has PC vs. Mac overtones only because iTunes / Music is bundled with Macs (and therefore very widely used).

iTunes has a preference setting to "Use error correction when reading Audio CDs". A note in the dialog indicates that using this setting can reduce import speed. For now, I am using iTunes to import CDs, but I am also importing CDs with this setting selected.

Well, okay... tomato, tomato. I just mentioned the PCvsMac thing because "many comments ago" people were like "PC guy here all the way."

At this point I'm just trying to determine why EAC seems to be seen by many as a more reliable - and even powerful - app than iTunes. So far I haven't found any explanation from a coding, or engineering, or even scientific perspective.

I think I'm gonna end up using iTunes for my project but since I'm here to learn, I'm trying my best to hear different perspectives.

Keep in mind that CD-Audio error detection and correction is not as thorough as CD-ROM, DVD-ROM, or DVD-Video error detection and correction.

If you get the same results twice in a row, that's not absolute proof that there were no read errors. It might just indicate that the drive ran into uncorrectable errors both times, and made up the same intermediate data both times, in the hopes that the data would be sufficient to fool the average human listener.

Thank you for replying to the original question I asked you.

What differentiates CD-Audio error detection/correction from the other aforementioned types?

One thing I should have mentioned in my previous question to you in my other post/reply, is that I got same results for rippings I did in different days (so I had to turn off the computer, etc.) when I decided to test several apps, procedures, etc. The results I got with iTunes and Audacity were pretty much the same. I have in the past got one or two mistakes when encoding to mp3, but I suspected that happened because I had other applications running in the background. I just wanted, really, to better understand about that process with the app that extracted audio over and over until it got 2 identical copies. And also how long ago you heard/read that claim because, as I noted, iTunes has probably improved ever since its early days. I wonder how many times one gets an error when using it to extract audio these days.

It's not a Mac versus PC thing. Exact Audio Copy can use an external compression program, and the LAME MP3 external encoder is generally considered better than iTunes at encoding MP3s. However, at higher bit rates it's debatable if you will be able to tell the difference. I have used iTunes on my Windows PC (I'm not a Mac user) at times to rip / encode CDs, and at higher bit rates the resulting MP3s sound fine to me. Most of my collection is ripped and encoded via EAC + LAME, though.

Yeah, I covered right above why I used the 'PCvsMac' "expression." Sorry if that was counterproductive.

Why is LAME MP3 external encoder that much better than iTunes? I took a look online on that matter a few years ago and wasn't able to find anything other than those answers that start with "I prefer/like LAME" and what followed after it was just personal preferences and nothing else based on anything very substantiated.

It basically boils down to how hardcore you are about absolute data accuracy, when ripping redbook audio cds. If you're dealing with audio cds which are not damaged/defective/rotting, the main problem will be jitter and compounded with how a cdrom drive's cache system functions..

CD Ripping Terminology - LinnDocs

docs.linn.co.uk

CD ripper - Wikipedia

en.wikipedia.org

Primarily read offset jitter from seeking.



This is actually the bane of some cdrom drives, where there is no easy standard way to "flush" the cache. So if a particular audio cd sector is read a second time, the cdrom drive will just get that "sector read" from the cache and NOT from re-reading the actual audio cd disc.

Some cd ripper programs had all kinds of algorithms which figured out ways to deliberately trick the cdrom drive into re-reading a sector from the actual audio cd disc, and not from the cache.

(Older cdrom drives did not have a standard "force unit access" command to re-read a redbook audio cd disc).

You brought something up that I forgot to ask in my original reply/post: how compromised would a CD collection ripping project be if one relied on an old CD/DVD-rom drive? I sometimes wonder if mistakes might occur due to old hardware and/or apps that are not updated. My CD-rom drive is from 2007! Ever since things started going digital, I never felt the need to buy new hardware for that purpose since my current laptop doesn't even have optical CD/DVD drive. Any time I need to read a disc I use this older computer (something that happens once every gazillion years). So what are your thoughts on the matter? In the end an optical drive isn't just about reading information? Has there been any significant improvement in optical drives?

If you're the type of person who is extremely paranoid about demanding absolute data accuracy, the only other option I can think of is to write your computer code. You can start off by looking at the source codes for open source cd ripper programs like cdda2wav or cdparanoia.

[...]

LOL. I love how you seem to think that the average HTForum user can just write code. I know some HTML and that's about it. Hahaha!

Every now and then iTunes will have typos in the name that it grabs, or more rarely, it grabs a foreign language for the titles. Or I just don't like how it titles songs.

iTunes just makes it easy for me - I'm still a PC guy, but I have an iPod, iPhone, iPad, and AppleTV and I love how everything talks to each other.

I have more than enough space on all of my devices so if I want a certain set of music in the car (ApplePlay FTW!) I just add it to my phone and it's all good.

Everything I rip is encoded as Apple Lossless and I can't tell any difference. My 101-CD changer hasn't been connected to my AVR is probably 15 years.

Thanks for replying to my original question to you. In the end I just wanted to know if it was a problem with the application or something caused by the DBs. Good to know iTunes is not to blame for that.

Also, welcome to my club: I also still own an iPod and I love it.

Just out of curiosity: how would you prefer for it to title songs?

 

[Thomas Newton]

What differentiates CD-Audio error detection/correction from the other aforementioned types?

The people who designed CD-Audio assumed that it was OK for there to be some non-correctable errors. The human ear and brain are not very good at picking up errors – if they were, then nobody would use MP3, AAC, or ATRAC, as those lossy formats introduce a continuous stream of errors into the audio data. So unless a CD player "skips" at error points, or is unable to play a disc at all, listeners generally have no idea when they are being fed made-up data.

With computer object code, every byte must be correct. Even one incorrect byte can crash an entire application. So when people went to adapt CDs for data use, they had to add more robust error correction. A CD formatted as a data disc, rather than as a Red Book audio disc, uses more of the underlying, raw storage of the media for error detection and correction codes.

On DVD-Video and Blu-Ray discs, video is highly compressed, using a lossy form of compression. This made it likely that if there were non-correctable errors reading the media, there would be major video and audio glitches. On top of that, the groups standardizing these formats wanted the ability to mix and match video and ROM content on the same volume/filesystem – not on different sessions/partitions, as on some CDs. That of course meant that the error correction requirements applicable to computer code applied.

 

[jcroy]

You brought something up that I forgot to ask in my original reply/post: how compromised would a CD collection ripping project be if one relied on an old CD/DVD-rom drive? I sometimes wonder if mistakes might occur due to old hardware and/or apps that are not updated. My CD-rom drive is from 2007! Ever since things started going digital, I never felt the need to buy new hardware for that purpose since my current laptop doesn't even have optical CD/DVD drive. Any time I need to read a disc I use this older computer (something that happens once every gazillion years). So what are your thoughts on the matter? In the end an optical drive isn't just about reading information? Has there been any significant improvement in optical drives?


LOL. I love how you seem to think that the average HTForum user can just write code. I know some HTML and that's about it. Hahaha!

It it highly dependent on the particular computer cd/dvd drive model. Even back in the day, some drives had an "accurate stream" feature where seek jitter problems are minimized or almost eliminated. If you're familiar with cdrom drive terminology, "accurate stream" drives have the same drive offset every time it returns back a sector read.

Some older computer cdrom (or cd/dvd rom drives) do not have an "accurate stream" feature, where the drive offset can be different with every sector read. I encountered this problem by chance when I wrote my own basic cd ripper problem back in the early-2000s. Some cd ripper programs were designed to handle this problem, such as EAC or cdparanoia. (IIRC, the "Fast mode" in EAC can handle this seek jitter problem on drives without "accurate stream"). EAC can test whether your current cd/dvd drive has "accurate stream".

Modern computer dvd drive models still being manufactured, usually will have "accurate stream" and will flag c2 errors. If you don't trust your old cd/dvd drive, you can always buy a current model. (Though current internal models are only sata nowadays). External computer cd/dvd drives are usually usb2 nowadays.

It turns out 2007 was around the time period when computer parts manufacturer went all-in with the sata interface.

 

[Guardyan]

It it highly dependent on the particular computer cd/dvd drive model. Even back in the day, some drives had an "accurate stream" feature where seek jitter problems are minimized or almost eliminated. If you're familiar with cdrom drive terminology, "accurate stream" drives have the same drive offset every time it returns back a sector read.

Some older computer cdrom (or cd/dvd rom drives) do not have an "accurate stream" feature, where the drive offset can be different with every sector read. I encountered this problem by chance when I wrote my own basic cd ripper problem back in the early-2000s. Some cd ripper programs were designed to handle this problem, such as EAC or cdparanoia. (IIRC, the "Fast mode" in EAC can handle this seek jitter problem on drives without "accurate stream"). EAC can test whether your current cd/dvd drive has "accurate stream".

Modern computer dvd drive models still being manufactured, usually will have "accurate stream" and will flag c2 errors. If you don't trust your old cd/dvd drive, you can always buy a current model. (Though current internal models are only sata nowadays). External computer cd/dvd drives are usually usb2 nowadays.

It turns out 2007 was around the time period when computer parts manufacturer went all-in with the sata interface.

Thank you, Jr. Learned a lot.

I'm googling my drive model but haven't been able to find specific info about it. Supporting Accurate Stream, C2 error flags and over-reading, seem to be features that are pre-requisites for secure ripping of CDs. Do you have any idea of where I should go to find that info? Is there a database for that anywhere?

I don't really wanna buy a new drive. To be perfectly honest, my drive has worked pretty decently over the years.

Noob question: is SATA interface inferior (or more problematic) than USB2?