Help - Search - Members - Calendar
Full Version: [feature request] Multiple album gain values for CUE sheets
Hydrogenaudio Forums > Hosted Forums > foobar2000 > General - (fb2k)
Fandango
For some reason you think the cue sheets is a good place to store these values... maybe it's time to put the RG values into the CUE_TRACKxx_* tag fields finally?

Well, the problem is that the album gain and peak values are stored at the beginning of the cue sheet and this makes it impossible to have multiple sets of album RG values for CDs with multiple album on them. Album gain will stay the one of the first album on the CD, all other album gains are not saved subsequently.
unsure.gif

To resolve this discrepancy without having to give up "RG in CUE" it would be possible to move REM REPLAYGAIN_ALBUM_* to the TRACKS, but honestly what's the point of having these things in the CUE sheet anyway?!? It's an old and unflexible file format, and it should be left that way.
Frank Bicking
QUOTE(Fandango @ Jul 26 2007, 03:37) *
CDs with multiple album on them

Does such a thing even exist?
Fandango
When I'm talking about "albums" I mean a collection of songs that is published as a set (on a medium) and not the medium itself.

http://en.wikipedia.org/wiki/Album

There are quite some re-issue CDs where they put two (or even more) albums and/or EPs onto one CD. It's also common to re-issue three albums on two CDs. Or even more in a bigger box set, where the boundaries of the CD format do not necessarily match the ending and beginning of the albums either.

Well, I'd really like to be able to apply album replay gain on albums and not on entire CDs only. These CDs are not so uncommon as you think. Actually, it surprises me a lot that you say you don't know about their existence. dry.gif
Fandango
Ah, yeah I get it. It won't change for whatever reason. dry.gif

Sorry for bothering you! mad.gif
Canar
Why not split them up into proper albums? That way each album can have its own RG and there's no problem. In the case of 3 albums on 2 discs, you can losslessly convert to 3 albums in 3 files if you're working with lossless. That way you fix the asinine packaging issue.

You're looking for per-album gain when your files are not already split into albums, and what's more, you want this from CUE sheets which already suck for metadata anyhow.

If you use the file-per-track paradigm, there's no issue here whatsoever.
Fandango
I don't want to break up the file as they are. I've ripped them into single files for each CD, not only for listening purposes, but also for backup purposes. And I don't want to keep redundant copies of the albums.

So personally I don't prefer single file for an album at all, the reason I use single files is because they represent the medium. For me this is how it makes sense.

Actually the really weird thing here is that there's almost no file-per-track paradigm with foobar2000 anymore, since the CUE_TRACKnn_* fields were introduced! BUT for some reason this wasn't expanded on the RG values!

The funny thing is that you can give some tracks of an image with embedded cue file a differing "album title" without a problem, because the differing album title is stored and then read from the CUE_TRACKnn_* tag fields. Actually I find the CUE_TRACKnn_ fields really nifty! One of the best new features of v0.9!

My proposal is to move the RG value to the CUE_TRACKnn_ tag fields and this issue will be resolved. Yes, it is an issue. Different records on the same CD, they really exist. And different recordings need different album RG.

As an alternative, in case RG value must stay in the cue sheets, it would be possible to move the REM REPLAYGAIN_ALBUM comments from the header to the corresponding TRACK sections. But as I said I don't like them there anyway, because I don't understand why they are still in the cue sheet. Why are they still in the cue sheet? Because of Burrrrn? Because of some "official" specs that say "album stuff must be in the header! track stuff must come after TRACK!"? Come on, that's impracticable! Just like the whole cue sheets are impracticable for storing meta data! Maybe there is another valid reason, but if no-one can explain that reason to me, I can't blame myself for not liking it. wink.gif

PS: I wouldn't have addressed this if there was another way. I appreciate your suggestion, especially because it is something I haven't thought about. But for me it is not a solution, but a subpar workaround that doesn't resolve the issue here.
Purple Monkey
QUOTE(Fandango @ Jul 27 2007, 20:50) *

not only for listening purposes, but also for backup purposes. And I don't want to keep redundant copies of the albums.

This is a bit picky but: Isn't the whole point of having a backup, is having redundant copies? Surely there is no harm with having a 3rd generation like most businesses do.

An alternative to cue sheets might be to use mp4 chapters if you can wrap the file into a mp4 container, I don't have any personal experience with that though.
Fandango
I just don't have or want to use the harddisk space for a second (even lossy) copy of the CDs. IMHO, it's inefficient.

No, I'm not looking for an alternative here, because I want to stick to foobar2000 and (plain) audio files with embedded cue sheets.

This thread is meant solely as a feature request or rather a request for a design change if you expand the request to "also relocate the RG values out of the cue sheet into dedicated tag fields".
Fandango
Hello? Any useful feedback on this is still highly appreciated.
Fandango
Bump
edwardar
+1 for this feature request

I have run into this limitation myself. I have a few of the beach boys double album CDs and I'd like to album replaygain the albums individually.
I came to the conclusion that I'd have to split the files, though that's a bit more manual work when ripping the files and more work required to burn the original back to CD.

Ed
odyssey
I see the point, but I don't really understand why you really need this. IMHO the point of having .cue files is to have a backup of the CD TOS and being able to burn an identical copy of the original CD. Which players does even utilize the RG values stored in .cue files? (Squeezebox?)
Martin H
He is talking about images, so cuesheets are vital for playback purposses. His problem is that cuesheets with two albums referenced, will both be played back with the same album RG value in fb2k and compatible players, because of the way fb2k sets the album RG REM entries in the cuesheets.

Personally, i would not like to have the album RG values moved to the tracks section, just to be able to fix this little and not so frequently happening "issue". If i had such kinda albums, then i would still be happy with one album RG value for each CD, but thats of course just my humble oppenion smile.gif

Btw, i personally like the use of REM entries for storing the extra metadata in cuesheets, since e.g. EAC sets them by default(which most of us use for ripping the images) and other tools also makes use of them like ACDIR etc. I find them much more convenient, than a bunch of extra tags in the images. And especially since fb2k already uses them for RG values, then i can't really see why we need to have two systems available which overlaps eachother ?

Just my two cents, though...
Fandango
QUOTE(odyssey @ Oct 1 2007, 20:11) *

Which players does even utilize the RG values stored in .cue files?

foobar2000 can do that... blink.gif Besides I'm actually proposing to move the RG values out of the cue sheets, since I don't see the point in bending this old and weary file format in this way by augmenting it with (as you rightly noticed) widely unused metadata.

QUOTE(odyssey @ Oct 1 2007, 20:11) *

I see the point, but I don't really understand why you really need this. IMHO the point of having .cue files is to have a backup of the CD TOS and being able to burn an identical copy of the original CD.

I listen to music on my PC only, it is connected to my amp. I have no CD player. I rip to single files with embedded cue sheets and so I get a backup of the CD and a music file for playback in one.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.