Pseudo release as solution for CD with Red Book indexes

MusicBrainz
, , , , , ,
1

The Red Book standard for CD’s contains the option to use indices within a single track position, although this implementation is rarely used.
It’s a way to for instance make divisions, within a single work, such as different pieces from the same opus work, or different movements/parts. Older CD players tend more to support this, so that you can go straight to the next index, as you can go to another track.

I just entered such a release, and also ripped it to my hard disk using EAC, dividing the tracks using these indices. Problem is of course: Picard doesn’t seem to support this Red Book implementation. To properly detect and submit a Disc ID, I need to enter the CD as if the index is one big track. But this way, Picard is not able to properly tag the ripped files. Neither does the tracklist on MB properly reflect the CD tracklist.

I asked in the MB Discord server, whether it is OK to use a pseudo release to fix this problem. It was indicated this was an OK use of the pseudo release, as it was not ruled out in the guidelines, but I would run the risk the pseudo release would be deleted at some point, as this use of the pseudo release wasn’t mentioned either. Moreover, this same problem would exist for anyone encountering a release using indices. So the best course was to take it to the forum and have it settled.

I also think a standard way for such a pseudo release should be settled and documented.

tagging @UltimateRiff @aerozol (zoe-division? I can’t find the username here…)

Both releases can be found here:

I used it as a test case prior to posting this topic.

Here are my experience:
Does this way work to properly tag the ripped files?:
Yes, but some things should be settled:

  • I used 1.1 / 1.2 / 1.3 / … in the tracklisting, Picard automatically makes this 1 / 2 / 3 /…, So probably it’s best to also simply use 1, 2, 3, … shifting the track positions compared to the CD, but as the tagged files don’t contain any indices, it probably has no advantage to try to reflect the original CD position in the pseudo release (I didn’t yet change this, now the pseudo release goes from 1.1 to 10, but the tagged files have 1 to 15, which is probably how it should be done.)
  • There is no proper release-release relationship to link the pseudo release atm. Currently this is solved by linking them in the annotation.

So currently the pseudo release seems to be a good solution to handle CD’s which contain Red Book compliant indices. Only a proper relationship should be introduced, such as “expanded index tracks” or similar description).

Obviously, towards the future, it would be better if both MB & Picard would simply also implement these Red Book indices by detecting them in the TOC. this should enable:

  • The individual indexes be entered in the tracklist with specifically formatted track positions, having a heading for the indexed track (Heading having position 1, index positions 1.1 / 1.2 /… or (as on the specific case) 1:1 / 1:2 / 1:3 /…
  • Track lengths of both the complete track & the index positions (the example case lists track lengths of the individual indices)

But I realise this implementation is not something to be expected in a near future. The addition of a proper relationship for such a pseudo release, however, can be used to if/when index implementation would be realised, to easily trace down the cases, and update them to the new situation.

Any thoughts on this test case & proposition to formalise the use of a pseudo release to expand the tracklist for tagging purpose, and to more accurately represent the tracklist of a release using them?

2 Likes
2

It’s a bit of a hack, but I don’t see a problem using pseudo-releases to store track splits per track indices, which seems to be an ‘artist intent’ way of dividing up tracks rather than a purely fan-made cut?

But I would be wary of opening the door to other ways of splitting releases/tracks… will get messy. I have a few rips I can’t tag with Picard (e.g. vinyl rips that are split differently to the back cover) and I think it’s fine to just live with it sometimes.

3 Likes
3

I also don’t see a big issues using a pseudo-release for this purpose (perhaps even an official release? a new type?), whether for CDs or other similar cases (like the vinyls case @aerozol mentions above)

I will note there is a similar case for YouTube full album uploads where it’s split into chapters, it’s currently unclear whether to split into tracks or not

one thing I will note on this point, it is possible to get these track numbers (see here for the scripting variable) (apparently it doesn’t use decimal track numbers but whole numbers?). either way, I think noting which MusicBrainz tracks are part of which CD tracks is important, especially since Picard isn’t the only data consumer of MusicBrainz data

1 Like
4

In case you didn’t see this:

5

MusicBrainz has consistently said pseudo-releases are for transl(iter)ated tracklists only.

What’s being described here probably fits best as Bootleg.

Actually, since the example under discussion is a reverse Classical split, I’m pretty sure @reosarevok has complained about people importing Classical releases from Discogs resulting in fake releases like what’s being discussed here. Am I remembering wrong?

6

how I read @reosarevok here is he’s open to other uses for pseudo-releases, not specifically excluding any uses (tho correct me if I’m wrong, of course)

I think using pseudo-releases like “releases that logically exist, but don’t physically exist” could be perfectly acceptable. this would include alternate splits of tracklists like this (whether CD, vinyl, digital, etc.) as well as translations and transliterations. how that might or might not work with Alternate Tracklists™, I’m not sure, but we can cross that bridge when we get there

5 Likes
7

Oh right, maybe bootleg is a better fit. My contribution was mainly that I think splitting based on track indices seems like it could fit into the database. In comparison to something like fan-made vinyl splits, which I don’t think fit.

FWIW there is a Picard ticket here for allowing a file to be matched to multiple tracks in Picard, e.g. you could tag a file that is ‘Side A’ to 5 tracks in Picard: https://tickets.metabrainz.org/browse/PICARD-2628

1 Like
8

I wouldn’t say this example here is a fake release like the usual other bad Discogs imports.

Here, sub-track indexes do physically exist and are valid per audio CD specs, but MB Disc ID doesn’t support them, and will probably never do.

I think pseudo-release is better suited than bootleg, because bootleg means it’s another request, while pseudo-release means that this is an alternate way of presenting the same release.

6 Likes
9

^^^ This is the description as I would understand it. You can’t call a legit release a bootleg. All that is happening is the track list is described in a different, more useable way.

If this was vinyl there would be no worries about doing a tracklist as written. As there is a discID we are locked to the disc format for the track count.

7 Likes