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: unsplitting flac from cue (Read 2902 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

unsplitting flac from cue

Suppose I have a per-track cue sheet and corresponding FLAC files.

I wish to create a single FLAC file for the whole disc, and a corresponding cue sheet.

I run Linux and prefer to work on the command line.

What are the best options?

Is this operation possible without loss?
 

Re: unsplitting flac from cue

Reply #1 –
The merging operation is possible without data loss, but the conversion of the splits to a cue sheet would only be lossless if the splits are from a CD rip or on the exact boundaries of what would be a CD rip. If not, then the cue sheet boundaries won't be exact.

Re: unsplitting flac from cue

Reply #2 –
Quote from: kode54 on
the conversion of the splits to a cue sheet would only be lossless if the splits are from a CD rip or on the exact boundaries.

Thanks for the reply.

Wouldn't this constraint almost certainly apply if the audio files and the cue sheet has been both generated from the same ripping operation?

Re: unsplitting flac from cue

Reply #3 –
If they were both generated from the same media, or the same pressing of the same album, it wouldn't matter really. Although for the pre-gaps, it might matter, since detecting those can be a bit problematic.

Re: unsplitting flac from cue

Reply #4 –
The premise is that a single disc was ripped into a cue sheet and a sequence of audio files. There is no possibility that the various audio files are taken from different media.

Re: unsplitting flac from cue

Reply #5 –
Gotcha. So you should be able to append them either with an editor or an audio player with a converter. Command line will be fun, I guess.

Re: unsplitting flac from cue

Reply #6 –
Right, so on a practical note, what is available in terms of tools that would automate the process, which includes concatenation of the audio and restructuring the table? For reference, I work almost entirely with open-source software running on Linux.

Re: unsplitting flac from cue

Reply #8 –
I'm afraid I don't understand AccurateRip, so I also don't understand what it would be do that is helpful for this issue.

Re: unsplitting flac from cue

Reply #9 –
Quote from: brainchild on
I'm afraid I don't understand AccurateRip, so I also don't understand what it would be do that is helpful for this issue.
AccurateRip stores
* Table of contents (to generate an ID for the disc)
* A checksum of the actual audio.
If your rip matches the checksum for the same CD, it means - up to some details about beginning/end of track - that you can be confident that someone else has the same rip as you. If that is the case, you don't need cache defeat, test+copy and all the cdparanoia stuff - you basically got your rip verified by an independent rip.
(CUETools has a similar database, which can also repair, but doesn't have the same scope.)

If you after the rip use CUETools and (successfully!) verify the rip, you also know that you have not messed up gaps upon splitting/merging the FLAC - for then, the table of contents would have ended up wrong and your CD would not have been found.

Re: unsplitting flac from cue

Reply #10 –
I understand your explanation. I have investigated AccuRip and CTDB, and have even used CUETools to repair a file I had previously ripped but was found inaccurate. This feature is tremendously valuable.

About reconstituting single-disc images, it seems viable, as long as the gaps are copied in the track files. Afterward, the result may be verified, as you suggest. As I learn about the structure of CDs, however, I begin to wonder whether one limitation of the process is that if the available track files have no capture of the HTOA, then it cannot be recovered. The best hope for the scenario I describe is that the operation to build the whole-disc image fills this region with silence, and that such an assumption is accurate for the original disc. 

Re: unsplitting flac from cue

Reply #11 –
The HTOA cannot be recovered, no - but often it is silence, and when it isn't digital silence it is often just that the "analogue near-silence" starts a bit early. Only rarely is there actual music in the HTOA, but it happens.

Re: unsplitting flac from cue

Reply #12 –
Actually, I am confused about the HTOA. I understand it is normally 2 seconds of silence, but most of my cue sheets show no entry for index 0 in the first track, and a time value of 00:00:00 for index 1.

For those sheets that do have an index 1 after the beginning of the audio, values are varied but generally close to 30 blocks (e.g. 00:00:30), which is less than half a second (75 blocks per second). Based on what I have read, I would expect most cue sheets to show index 0 of the first track as the beginning of audio, and 00:02:00 for index 1.

Re: unsplitting flac from cue

Reply #13 –
I think you're confusing HTOA with the 2 second (150 sector) lead-in area. The program area (where the audio data is) follows the lead-in. HTOA is in the program area, after the lead-in but before the start of Track 1.
CUE sheets start in the program area so if Track 1 starts immediately following the lead-in, it starts at INDEX 01 00:00:00.
https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio#Data_structure
korth

Re: unsplitting flac from cue

Reply #14 –
If the two-second lead in precedes even the pre-gap for track 1, then what is its purpose? Is it ever played?

Re: unsplitting flac from cue

Reply #15 –
I provided a link
korth

Re: unsplitting flac from cue

Reply #17 –
Hopefully I will be able to look at the details of the document at some time.

It seems that the summary answer is that the TOC information is placed in the lead in, but since the lead in follows the same format as the program area, which only allocates a designated interval of the bitstream for such information, the audio padding is needed such that the the region offers enough space for the TOC.

From my way of thinking, being more familiar with formatting schemes seen in computer files, it is more practical to keep a metadata header containing indexing data partitioned separate from the audio data that would follow.