Rip as One FLAC with CUE sheet or... what?

[Lossless Nesman]

Been away from ripping for a while and wanted to do a fresh rip of my CD library as a final kind of archive. Planned on doing FLAC single file per album with a CUE sheet. (Embedded or not, I don't know yet. Still learning about cue sheets.) But then I'm reading in Roonlabs forums that they don't plan supporting cue sheets because it's an outdated, obsolete technology. I don't use Roon, at least not yet, but it still got me wondering, is there something superior that I should be doing instead?

My goal is to have a (backed-up) archive of my library that is as close to completely accurate as possible. That includes the kind of information from cue sheets like gaps, lead-ins & outs, etc. (As an aside, recently I learned about pre-emphasis, something I have experienced with old discs, but didn't understand. That's another thing I'll have to take into account when doing my rips. If anyone knows of other pitfalls like this, please educate me!)

Anyway, should I proceed as planned (considering my stated goal) or is there a better way to go?
Thanks for any wisdom.

[Spoon]

It is more flexible if your tracks are not saved as one single track, there is no need to do this. Gaps are there for a reason, two different tracks would cause a pop if played together with the gap removed, for gapless albums they are always ripped as gapless anyhow.

[garym]

It is more flexible if your tracks are not saved as one single track, there is no need to do this. Gaps are there for a reason, two different tracks would cause a pop if played together with the gap removed, for gapless albums they are always ripped as gapless anyhow.

Confirming this. I have lots of gapless CDs, and ripping to regular (separate) FLAC files maintains the lossless playback on all my various players. CUE Sheets had their use in the old days before codecs got better (and could handle gaps properly). Not needed in modern times (which is why Roon is adamant about NOT supporting CUE files).

[BOOTP]

Confirming this. I have lots of gapless CDs, and ripping to regular (separate) FLAC files maintains the lossless playback on all my various players. CUE Sheets had their use in the old days before codecs got better (and could handle gaps properly). Not needed in modern times (which is why Roon is adamant about NOT supporting CUE files).

I would agree and say that 95%+ of people do not need CUE files...

However, the poster used the word 'archive' and that can be somewhat different to just ripping your CD library for listening to, even in a lossless form. I say this because an archive generally means you will want the opportunity to reproduce a physical audio CD exactly as per the original CD - and without a CUE file you cannot do this as the gap information etc. will not be stored anywhere. You can still burn the audio files to a blank CD as is, but what you will find is the newly burnt CD will not show the same in CD Ripper / AccurateRip simply because the structure of the burnt CD will be different. Also, if you put the burnt CD in a traditional CD player you would not get the count up to 00:00. If you used the CUE file to burn the CD then CD Ripper would display the information and work as if the original CD was being used.

Note that I would still 100% rip to single tracks in FLAC and not a single FLAC file as the latter is really cumbersome. If I need to generate a CUE file for individual tracks, then this is the only area where I use EAC in my workflow as it handles CUE file generation much better and without the need to rip again - just pop in the CD and use the option 'Create CUE Sheet' --> 'Multiple WAV Files With Gaps... (Noncompliant)'. Don't worry about the noncompliant bit - you need this option to make a useful CUE file to work with seperate track files.

Burning a CD with a noncompliant CUE file still involves more work though as you need to use EAC to burn the CD - assuming you are ripping to FLAC originally you would need to convert the files to WAV and then update the CUE file contents to match the new filenames of each track (this can be done very easily with CUETools). Once you load the new CUE file into to EAC you will get a nice visual of the CD structure and how the tracks are positioned with the gaps etc.

Is all this worth the effort? Probably not. Most people who do this believe a rip is only 'perfect' when you have the audio, log file, and CUE file.

[Lossless Nesman]

Thanks for the replies. Some things for me to think about. I just got my new ripper machine built and am starting to experiment when I have time. I did say I was looking to archive my discs, and that's true, but when I try to be really honest with myself, would I ever *actually* want/need to re-create a perfect physical CD copy at some point down the road? Probably not, even though the obsessive part of me whispers "but maybe you will." The someday-in-the-future high(er)-end audio system that I aspire to will almost certainly be based around a network player/DAC type setup rather than a CD player or CD transport/DAC setup. So getting accurate lossless rips should be completely sufficient, I say, trying to convince myself.

I think my takeaway is: The accumulated wisdom is that the flac/CUE (or BIN/CUE) format carries too high a cost for the few benefits it comes with, or perhaps the only benefit it comes with - the ability to recreate a "perfect" physical CD. Unless that goal is paramount, it's just not worth it, correct?

I will refrain from immediately asking my current questions on gaps and index 0 audio until I have time to do some more experiments, at which point I will post a new topic if needed.
Thanks guys!

[garym]

I think my takeaway is: The accumulated wisdom is that the flac/CUE (or BIN/CUE) format carries too high a cost for the few benefits it comes with, or perhaps the only benefit it comes with - the ability to recreate a "perfect" physical CD. Unless that goal is paramount, it's just not worth it, correct?

In my opinion, correct. I've spent years ripping my 9,000 CD library to lossless FLAC. I've learned enough to manage a nice linux based home server to feed all this music to endpoints in my house systems. I've developed robust backup procedures for my digital files. Why in the world would I ever want to re-create a physical disk? If my house burned down, I'd still have all my digital files and I wouldn't consider for even a split second the idea of re-creating the physical CDs. (In fact, I think I'm probably a bit too obsessive with simply keeping all my physical CDs, stored away and never looked at. I should probably get rid of them. I do tend to like following the law however, and where i live (the US), if I dispose of the CDs, I don't legally have the right to retain my digital rip from the CD.

[BOOTP]

I think my takeaway is: The accumulated wisdom is that the flac/CUE (or BIN/CUE) format carries too high a cost for the few benefits it comes with, or perhaps the only benefit it comes with - the ability to recreate a "perfect" physical CD. Unless that goal is paramount, it's just not worth it, correct?

Correct. If you do not need to reproduce the original CD then there is absolutely no need for CUE files in 2021.

If you are unsure at this stage then just get the CUE file for your first batch or two of rips (it takes less than a minute) - you will soon see how you probably don't need them. I might be wrong but I believe Spoon added the CUE DSP to appease a minority who were adamant in wanting this feature (the long CUE file thread is a good read by the way, and I'd still suggest EAC for generating CUE files).

Keeping CUE files also means you need worry about non-standard CDs, as technically you will need to extract and store the non-audio section of a non-standard CD...

To be honest, it is easy to get on the OCD train of needing all these extra logs and files to 'preserve' your audio library, but if you rip properly then ultimately the audio files contain everything you need in this sense with the two AccurateRip tags.

In fact, if you rip and later run the audio files through PerfectTunes then the AccurateRip tags will update to the latest values in the database - hence the log files become even less useful!

[garym]

In fact, if you rip and later run the files through PerfectTunes then the AccurateRip tags will update - hence the log files become even less useful!

I'm pretty sure (virtually positive) that PerfectTunes does not rewrite the AccurateRip tags. Yes, one can run PerfectTunes to recheck the AccurateRip match status at any time. PerfecTunes is reading the audio from the files, creating a temporary CRC, and then comparing this to the one in the AR database. I often do this for new CDs that weren't in the AR database when I ripped.

[BOOTP]

I'm pretty sure (virtually positive) that PerfectTunes does not rewrite the AccurateRip tags. Yes, one can run PerfectTunes to recheck the AccurateRip match status at any time. PerfecTunes is reading the audio from the files, creating a temporary CRC, and then comparing this to the one in the AR database. I often do this for new CDs that weren't in the AR database when I ripped.

Yes, you're right - I was thinking of CUETools which can run a 'Verify' operation and that does have the option to write AccurateRip tags (although the numbers of tags and the data is very different to the standard two tags provided by CD Ripper).

The ability to update the confidence interval should really be a standard option in PerfectTunes - it should not be that difficult to implement considering the data is already output in the PerfectTunes log at the end.

For example, my original tag for a track is:
AccurateRip: Accurate (confidence 129) [2FF7AA9B]

After running PerfectTunes, the log shows:
Track 1: AccurateRip Verified Confidence 144 [CRC 2FF7AA9B]

Given the odds, going from 129 to 144 here is pointless though. However, updating the confidence interval would be most beneficial for those CDs where the confidence interval is 1 or 2, or the CD was not in the AccurateRip database at all when ripped (I have a number of these).

I would still keep it as an option though as I'm sure some people will be upset the confidence interval in their initial rip logs no longer matches the confidence interval in the audio file.

Regardless of all this, if you have the two initial AccurateRip tags from ripping I still say there is no need for much else in terms of CUE files and logs.

[nemo]

I found this thread because I have a similar aim to Lossless Nesman...

wanted to do a fresh rip of my CD library as a final kind of archive. Planned on doing FLAC single file per album with a CUE sheet.

The universal opinion about single file rip (with a CUE) seems to be that it was less flexible, and ONLY required if you plan to reproduce the original CD.

However, I have a usecase where I think a single file rip is MORE flexible: I don't always agree with the track divisions on the CD.

Granted, it's rare, but creating a custom CUE file with my own timing divisions, and then splitting the flac by that - strikes me as far easier than trying to fix timings when everything is already split up.

Am I the only one who has encountered this frustration with an album?

[garym]

I found this thread because I have a similar aim to Lossless Nesman...



The universal opinion about single file rip (with a CUE) seems to be that it was less flexible, and ONLY required if you plan to reproduce the original CD.

However, I have a usecase where I think a single file rip is MORE flexible: I don't always agree with the track divisions on the CD.

Granted, it's rare, but creating a custom CUE file with my own timing divisions, and then splitting the flac by that - strikes me as far easier than trying to fix timings when everything is already split up.

Am I the only one who has encountered this frustration with an album?

for albums I want to play in a different track order, I simply create a "playlist" for the album with the tracks in the desired order.

[nemo]

for albums I want to play in a different track order, I simply create a "playlist" for the album with the tracks in the desired order.

That misses the point entirely. I'm not talking about a different order. I'm talking about different timing points of the existing tracks.

The album this first came to my attention on has track introductions at the end of the previous track (technically in the pregap I believe, I'd have to dig up the original CD to tell). I want to change the track timings so the introduction to each track is at the start of the track.

Your suggestion of a playlist to change the order is in fact where this gets annoying. When the album is played in original order, it's a non-issue!

[GBrown]

That misses the point entirely. I'm not talking about a different order. I'm talking about different timing points of the existing tracks.

The album this first came to my attention on has track introductions at the end of the previous track (technically in the pregap I believe, I'd have to dig up the original CD to tell). I want to change the track timings so the introduction to each track is at the start of the track.

Your suggestion of a playlist to change the order is in fact where this gets annoying. When the album is played in original order, it's a non-issue!

I have at least two discs with this issue.
KISS - Smashes, Thrashes & Hits
Kim Mitchell - Akimbo Alogo

I ripped these as disc at once then manually split them. I couldn’t find any other solution at the time.

[garym]

That misses the point entirely. I'm not talking about a different order. I'm talking about different timing points of the existing tracks.

The album this first came to my attention on has track introductions at the end of the previous track (technically in the pregap I believe, I'd have to dig up the original CD to tell). I want to change the track timings so the introduction to each track is at the start of the track.

Your suggestion of a playlist to change the order is in fact where this gets annoying. When the album is played in original order, it's a non-issue!

Got it. I understand your issue now.

[GBrown]

Yes, it is the pre-gap that is incorrectly used. I believe this was may have been an early effort to thwart piracy, but it could have also just been poor mastering techniques as well.

I tried to find a way to rip with the pre-gap moved to the front of each track rather than trailing, but couldn&*8217;t. I think the DAO method worked ok though, and actually had better control of where each track separator was in my opinion.