55-disc release split into 55 pseudo releases "for better tagging purposes"

Tags: #<Tag:0x00007f7d01b35af8> #<Tag:0x00007f7d01b35918> #<Tag:0x00007f7d01b35738>

Please look at this release group.
It is about a 55-disc release. In January 2017, editor marlonob has added 55 pseudo-releases, one for every single disc, with the edit comment “Separate the albums in individual pseudo releases for better tagging purposes.”

In my opinion, there is no good reason for having those pseudo-releases in the database and thus, I suggest merging them into the full 55-disc release. Editors steinbdj, Senax and reosarevok have indicated that they agree.

As the creation of all those pseudo-releases must have been a lot of work, I would like to have a general disussion here and learn about your opinion, before going ahead.


I agree and don’t see any value for the pseudo releases, not even “for tagging purposes” (and that’s anyway no good reason to perform any stunts with the database).


I also agree. What’s there now just looks wrong to me.

While there are certain circumstances that would necessitate a pseudo-release for “better tagging purposes” (e.g. this), this does not look like one to me. Perhaps that editor is unaware of the Classic Disc Numbers setting in Picard?

From memory and a limited understanding:
There was a time within the last 2 years when the server was not able to cope with tagging large box-sets unless ? “Don’t included extended relationships” ? was set. The recommended work-aroubd was to use only incomplete tags.

If this remains the case then merging will preclude the tagging of this release with full tags.

I’d suggest ensuring that full tagging of the 55 disc set is available before merging.


Just wondering if the motivation of the original editor was to prevent Picard from looking up all 55 if someone just has one of the discs they want to tag or, maybe, has some of the recordings on different releases. It would be time-consuming and irritating if you get 55 discs just to attempt to match one recording!

I can come up with one good reason to do this:

I suspect trying to load https://musicbrainz.org/release/3848dbd0-0aea-4ac6-bd72-4d0c19995c37/edit-relationships would be an exercise in frustration (one which I definitely wouldn’t attempt without making sure I’d saved everything else I care about in the browser, and had set a memory limit on it). So I can see the value of splitting the release — and pseudo-releases don’t really cause any harm. A few 10- or 20-disc splits would have been my choice, though.


There is an issue with the database and loading large box sets doesn’t return full information. The query works (after a long time), but it doesn’t return relationship data even if that option is checked.

If these releases are merged, how would it be possible to fully tag those releases? I support this split.

See: Relationships not returned by XML webservice