Difference between revisions of "Talk:Style/Titles/OC ReMix series"

From MusicBrainz Wiki
Jump to navigationJump to search
(New page: This contents of this page is derived from discussions on the mailing lists: [http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-September/000405.html http://lists.musicbrainz.o...)
(No difference)

Revision as of 15:27, 15 March 2009

This contents of this page is derived from discussions on the mailing lists: http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-September/000405.html, http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-October/000502.html


This style guideline doesn't reflect the official specification at OC ReMix. I asked about this discrepency in the #ocremix channel, and all I got was hostility:

I didn't get any sort of an answer after that. This style guideline should probably be fixed to match this line in the official standard tagging specification (the lines that pertain to OCReMix are highlighted in red on that page):

4.2.1 TT2 Title/Songname/Content description ALWAYS = Exact name of Game [space] Exact name of ReMix [space] OC ReMix E.G. Actraiser Fillmore Funk OC ReMix

Either that, or djpretzel should update his specification to match the style guideline described on this very page, based on the mailing list discussions, which stem directly from his input on the matter.

Also, is it possible to have a thousand-track album? If so, then all OC ReMix tracks should be moved over to one album, which is how djpretzel said he wanted it to be presented.


  • And I finally thought we had this figured out :( I don't think it should be change without clarification from DJP, though. It would certainly be nice for MB and OCR to be 100% consistant to the extent that's possible. A 1500-track album isn't realistic at present because albums are displayed on a single page, and the text for each table row can approach 1 KB, therefore the "Album" page would be over a megabyte, in addition to be completely unpresentable. I don't think it would work so hot in Picard, either. Even if these limitations could be overcome, there's the second problem that there can't be "gaps" in an album, ie. track numbers with no track associated with them. Quite a few tracks have been removed from OCR, so for each of these, the tracks after it would have their "track number" reduced from their actual OCR number. Also, I don't think it makes much sense to put a number in the "Track number" field anyways, because the files distributed by OCR don't. It would be nice if MB had some way to represent a grouping of tracks apart from an "Album". --loopy

We could group into albums representing OCR's distribution collections (1-250, 251-500, 501-750, 751-1000, 1001-1250, 1250-current; last I checked). --SailorLeo