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: EAC problem: Rips are not in a single big file, but every tune in separate file. (Read 764 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC problem: Rips are not in a single big file, but every tune in separate file.

Hi, I am kind of an EAC newbie.
I have a EAC problem. When I rip tunes from a music-CD with EAC, the tunes in the album are not ripped in a single big FLAC-file, but every tune is ripped to a separate FLAC-file.
How can I fix this problem?
But I don't know if this really is a "problem", maybe it's OK to have EAC rip each tune from the album in a separate file, for compatibility?

Thanks.

Re: EAC problem: Rips are not in a single big file, but every tune in separate file.

Reply #1
A single big file in EAC is called an Image and FLAC is compressed

korth

Re: EAC problem: Rips are not in a single big file, but every tune in separate file.

Reply #2
Thanks korth!
I read a EAC-guide that said that I should:
"1. Tag the album"
then
"2. Detect Gaps”
then
"3. Create CUE Sheet -> Multiple WAV Files With Gaps… (Noncompliant)"
then
"4. Test & Copy -> Compressed."

So I wasn't sure if I could do that method you said, without testing (for better quality CD-rips), but I guess that I can test separately, using,
"Test selected tracks".

Re: EAC problem: Rips are not in a single big file, but every tune in separate file.

Reply #3
It was just an example.
You can use the next action down "Test & Copy Image & Create CUE Sheet > Compressed" if you prefer.
korth

Re: EAC problem: Rips are not in a single big file, but every tune in separate file.

Reply #4
Thanks again korth, I'll use that.

Re: EAC problem: Rips are not in a single big file, but every tune in separate file.

Reply #5
Unless you have a very good reason to, you should be ripping to tracks and not to a single FLAC file. The biggest reason is compatibility, but even if you're using software that can cope with it you'll probably be limited in metadata support (even foobar won't read many tags from a CUE sheet).

With respect to checking that your rip is accurate, EAC should produce a log stating whether your rip has matched that of previous rips (AccurateRip and CTDB).

I haven't gone through them in detail, but there are some decent tutorials here.

Re: EAC problem: Rips are not in a single big file, but every tune in separate file.

Reply #6
Should be noted that converting to tracks later is easy with CUETools. And the other way around.
No reason to re-rip if one has already done a hundred.

Re: EAC problem: Rips are not in a single big file, but every tune in separate file.

Reply #7
Quote
rip each tune from the album in a separate file,
It is my personal preference to do so.

If you have a single file, you need a separate table of contents telling you where each track starts, what its tile is, etc.
This is called a CUE sheet. If you move your audio file e.g. a rename based on tags, the audio file will be moved but the cue might stay in place. However some formats allow for embedding the CUE.
The CUE syntax is rather limited. https://www.thewelltemperedcomputer.com/KB/CueSheet.htm
I use a lot of custom tags so no cue sheet for me.

The single file has one advantage, it will play gapless even on media players/ servers (DLNA) not supporting gapless playback.
TheWellTemperedComputer.com

Re: EAC problem: Rips are not in a single big file, but every tune in separate file.

Reply #8
I think im also on the seperate file train. Single file can create annoyances when trying to do conversions and editing tags.

Re: EAC problem: Rips are not in a single big file, but every tune in separate file.

Reply #9
If you have a single file, you need a separate table of contents telling you where each track starts, what its tile is, etc.
This is called a CUE sheet. If you move your audio file e.g. a rename based on tags, the audio file will be moved but the cue might stay in place. However some formats allow for embedding the CUE.
The CUE syntax is rather limited. https://www.thewelltemperedcomputer.com/KB/CueSheet.htm
The CUE will hold information about pregaps and data tracks so it is important to keep them (at least if the disc contains any of those) for verification purposes. It'll also hold other metadata not stored in the audio such as multiple index markers and pre-emphasis flags (both very rare) so I would recommended keeping them.

The single file has one advantage, it will play gapless even on media players/ servers (DLNA) not supporting gapless playback.
Are there still servers that don't support gapless playback!
I'd imagine/hope that 99.9% of people are storing their files as tracks, the rest are just stubbornly refusing to change because it's how they've always done it :-)

Re: EAC problem: Rips are not in a single big file, but every tune in separate file.

Reply #10
Quote
keep them (at least if the disc contains any of those) for verification purposes.

Don't think so. I have tracks only. These are sufficient for a lookup in any internet database as far as meta data is concerned. If you ever want to burn an audio CD being an exact copy of the original  one indeed needs the CUE. If I rip, I simply don't generate a CUE,

Quote
Are there still servers that don't support gapless playback!

Even worse, it is not part of the DLNA standard. Now that DLNA is gone, you might hope they adhere to UPnP and this one does support gapless playback.
TheWellTemperedComputer.com

Re: EAC problem: Rips are not in a single big file, but every tune in separate file.

Reply #11
Quote
keep them (at least if the disc contains any of those) for verification purposes.

Don't think so. I have tracks only. These are sufficient for a lookup in any internet database as far as meta data is concerned. If you ever want to burn an audio CD being an exact copy of the original  one indeed needs the CUE. If I rip, I simply don't generate a CUE,
If track 1 has a pregap and you haven't added it to the beginning of track 1 (I hadn't even considered that), nor do you have a record that track 1 actually contains more samples (within a CUE), then the TOC of your rip will differ from that in database.
In CUETools, CTDB lists the possible matches but AccurateRip doesn't, it'll simply say that the disc isn't recognised.

I've tried MusicBrainz Picard and whilst it does find the disc (amongst other matches) it doesn't match track 1, and the MusicBrainz plugin in foobar fails too (I assume it does a pure TOC match), so I don't know what software you're using. Obviously if your files are already tagged then software may be using that for a lookup, so I had removed these for the tagging test.

 

Re: EAC problem: Rips are not in a single big file, but every tune in separate file.

Reply #12
If you have a single file, you need a separate table of contents telling you where each track starts, what its tile is, etc.
This is called a CUE sheet. If you move your audio file e.g. a rename based on tags, the audio file will be moved but the cue might stay in place. However some formats allow for embedding the CUE.
The CUE syntax is rather limited. https://www.thewelltemperedcomputer.com/KB/CueSheet.htm
The CUE will hold information about pregaps and data tracks so it is important to keep them (at least if the disc contains any of those) for verification purposes. It'll also hold other metadata not stored in the audio such as multiple index markers and pre-emphasis flags (both very rare) so I would recommended keeping them.

The single file has one advantage, it will play gapless even on media players/ servers (DLNA) not supporting gapless playback.
Are there still servers that don't support gapless playback!
I'd imagine/hope that 99.9% of people are storing their files as tracks, the rest are just stubbornly refusing to change because it's how they've always done it :-)

Ye i found out jellyfin doesnt, appearently. God i might as well store my music on an ftp server christ sake. ^^