Track description metadata from a whole disk flac archive is ignored upon individual track rendering

[alan-hanna]

I started into this thinking it was a bug report, but maybe it is more of an enhancement request. I'm having a problem when using whole disk flac archive files for later abcde track separation. Creating a whole disk flac results in a single file that already has all the track description metadata embedded in the file. For some difficult disks, I have to manually edit the results of the MusicBrainz lookup to get satisfactory track description tags (mostly due to inconsistencies in the original MusicBrainz database data entry, I think).

What I expected: If I use the whole disk flac as abcde input to produce a set of separate track files (possibly converting to MP3 or Ogg in the process) I'd like for the per-track metadata to be automatically (or at least easily) transferred from the whole disk flac over to the appropriate separate track output files. If I've done any editing to fix up the results from the original MusicBrainz lookup, I'd like for the edited versions of these metadata tags to be used for subsequent track file generation.

What actually happens: Even though the edited and corrected track description metadata was already embedded in the whole disk flac file (which I can confirm with metaflac), the attempt to produce separate track files always presents either a fresh MusicBrainz search that loses all of my corrections, or I can select completely blank tags that lose all my corrections. Either way, I have to repeat all of the editing I already did in the first place, and I have to do this every time I use that whole disk flac for subsequent track file generation.

What I'd like to see: I'd like to see my own edits to the original MusicBrainz tags, presented as an option for use in generating new separate tracks. This could be as an additional choice where I'm currently present either blank tags or fresh MusicBrainz lookup tags for editing. Or perhaps this could be a substitute for offering the blank tags in the case of a whole disk flac (instead of a fresh CD drive rip) used as input. Either way, it would be ideal if one simple selection should cause the emitted track metadata to adopt any pre-existing edits contained in the whole disk flac. I most likely wouldn't need to make any changes, so I could just make that selection and then decline further edits and be done.

My system setup: I am using Debian 13 Trixie, with the stock abcde replaced by abcde 2.12.2 using the update procedure and *.deb file from github.com/poddmo/abcde/.

I used the following CD for my test: "Leap of Faith" (Audio CD, Soundtrack, December 8, 1992)

I created the whole disk flac using: 'abcde -1 -o flac -a default,cue'

I invoked track separation using: 'abcde -o flac -d ../Various-Leap_of_Faith/Leap_of_Faith.flac'

As nearly as I can tell, everything else is working great aside from this issue. In particular, producing the separate tracks all worked and the tracks are perfectly playable, they just are tagged with the faulty track descriptions from MusicBrainz for this particular disk.

I manually checked for my metadata changes in the whole disk flac, and my track descriptions are definitely in the flac and they are the corrected versions. They don't seem to be in the form of proper flac metadata tags though, they look more like part of an embedded cue-sheet specification as a CUE/TOC file, and maybe that has something to do with the problem. Besides that, there seems to be a separate and more official-looking embedded cue-sheet (in a metadata block actually labeled as "type: 5 (CUESHEET)") with more low-level specifications but no track program descriptions at all, and somehow looking like it might be rendered in some kind of JSON format. It's not clear to me exactly what needs to be present for this to all work.

BTW, thanks for all of your hard work to keep abcde relevant. I am blown away by the sheer usefulness of the concept of a whole disk flac. I suspect that what I'm asking for is harder than it looks.

[alan-hanna]

Since this has morphed from a bug report into an enhancement request, I thought I could do a little investigation to help scope out the difficulty. I'll pass this along for poddmo to do with as he will:

1. It looks like the program description I'm concerned about comes in from MusicBrainz and appears under the abcde.660a6c09 temp directory as file abcde.660a6c09/data-musicbrainz/cddbread.1. This file seems to be the starting point for any editing.

2. The results of the editing appear in the file abcde.660a6c09/cddbread.1 and in exactly the same format as the original from data-musicbrainz/, but this version has all editing corrections.

3. All track description changes currently appear in the whole disk flac as a metadata tag named CUESHEET. The value of this tag is the entire content of what could be a CUE/TOC file, with TITLE and PERFORMER fields filled in with final changes. So I think that these values must be drawn from abcde.660a6c09/cddbread.1 as the CUE/TOC file content is generated.

In principle, the cddbread.1 content could probably be regenerated from the CUESHEET metadata tag value. That sounds like a lot of work, though.

As a modest proposal, could we consider adding a new flac metadata tag to convey the content of the edited abcde.660a6c09/cddbread.1 file?

Perhaps a new (possibly optional) tag named CDDBREAD, whose value would simply be the full contents of abcde.660a6c09/cddbread.1 after editing. Its presence could be optional based on whether the original cddbread.1 data were edited. If there was no editing then there would be no need for this tag. Or the tag could always be present, just as a record of what MusicBrainz delivered at the time the whole disk flac was created (which actually might be interesting if the MusicBrainz database were ever updated and the user actually preferred the earlier form). This would make the whole disk flac file about 1-3KB larger, if and only if the new tag is used (actual size was 1263 bytes on my example disk with nine audio tracks).

If the CDDBREAD tag is found to exist when a whole disk flac file is used as "-d" input to abcde, then the content from the CDDBREAD tag could be presented as one choice for the source of program description info alongside the current MusicBrainz cddbread.1 content. It could just be selected for direct use or could be selected and then edited further, just as if it were the live values from the current MusicBrainz lookup. Maybe an easy way to use it could be to simply copy the content into the current abcde.660a6c09/cddbread.1 file, before the content of the file is processed for track tagging.

If there is no CDDBREAD tag in a "-d" input whole disk flac file, then there is nothing to do with it and there is no change to current behavior, so this would not break any existing whole disk flac files. If you decide to make its existence completely optional in any way, then there would be no increase in whole disk flac file sizes for cases where there are no custom edits to the MusicBrainz data.

As I say, a modest proposal, for your consideration.

[alan-hanna]

To be a complete Devil's Advocate here, I'll say a few words in defense of actually going to the trouble of parsing out the already-stored contents of the CUESHEET metadata tag. It would be a pain to set up and perform the parsing, BUT that would mean that old whole disk flac files collected months or years ago would now be processed correctly, because we would not need to make any changes to the file format at all.

Could be intriguing, if you are a big fan of not changing existing file formats even in backward compatible ways. This would remain forward and backward compatible. That CUESHEET tag already contains all of the required per-track information.

[poddmo]

Thanks for the report. I tested this and understand the problem. Two things come to mind:

• since commit 9926fcb we have a complete CUESHEET embedded in the whole disc flac. This should be available for tagging tracks encoded from whole disc flac. Where we already have local CDDB, musicbrainz, gnudb and cd-text methods for metadata lookup, if the source is a whole disk flac and there is an embedded cuesheet, then use that to generate a cddbread.n file that the user can select from.
  • this should be the preference metadata source for whole disk flacs
  • test with single and various artist sources
• embedded cover art should also be available for use when rendering a whole disk flac out to individual tracks

I see whole disc flacs as the future of cd encoding: one disc (or disc set) = one flac file. Being able to render those out to individual tracks is important and should reference the source's metadata. I'll mark this as an enhancement.

[alan-hanna]

Your summary of proposed changes completely addresses my issue. Thanks!