View Full Version : Submissions - Catalog Numbers
Secret Squirrel
Mar 20, 2010, 06:49 AM
Current Guidelines
Catalog numbers are publisher or distributor specific. They usually come in the form of an alphanumeric stem followed by a numerical sequence. Please avoid entering IFPI codes, barcodes or ISBN numbers.
For albums that span multiple discs, indicate multiple catalog numbers (if applicable) with a tilde.
Don't repeat a number after the tilde (e.g. VICL-1356~7, not VICL-1356~57).
Be sure to prepend zeros, where it is a convention (e.g., SCDC-00535, not SCDC-535).
It is not always necessary to follow the formatting of the catalog number as printed on the album. Use the format STEM-NUM~MULTI for catalog number runs where it is apparent that the intent was to use a number similar to this format. (e.g., LC-1541~2 instead of LC1541~2)
Some albums may not have catalog numbers, especially discs released as bonus or promo material. In these cases, leave the field blank.
Changelog
24-Mar-2010 -- Agreed to standardize on the format STEM-NUMBER~MULTIDISC for catalog number runs where it is apparent that the intent was to use a number similar to this format.
Technical Changes to Implement
Incorporate improvements to search for variations.
Expand catalog number search to cover the media table (to pick up independent catalog numbers in multidisc albums.)
Proposed Changes for Discussion
Ira
Mar 20, 2010, 11:30 AM
Should we keep replacing spaces with dashes in the LC-* series?
I'll mention again that they don't use dashes on konamistyle.jp (http://www.konamistyle.jp/item/itemsrch.php?srch=LC&sortorder=1&searchnumber=1&qPage=1). It is also printed this way on the albums (Ex: 1 (http://vgmdb.net/db/covers-full.php?id=48505), 2 (http://vgmdb.net/db/covers-full.php?id=38020), 3 (http://vgmdb.net/db/covers-full.php?id=67503), etc. I can also personally confirm Denjin k, though we don't have scans.) So, no, we should not keeping doing this.
Datschge
Mar 20, 2010, 11:41 AM
I would make all of that be handled by the database, i.e. turn the usually alphabetical part into an enum, give separate text fields for entering the first and (if it is a multipart product) last item's number. Then showing the number in a correct way can be handled automatically, and the amount of digits (non-used filled with leading zeros) as well as choosing the separator can be made dependent on the publisher or easily changed globally.
Cedille
Mar 20, 2010, 07:02 PM
Do you think we ever need an instruction message like "Please don't guess the catalog number even when it's too obvious for you"? I don't think so many submitters do that, but for some smaller vendors it's certainly easy to predict what comes next, and in one of the few cases where I saw people adding the next catalog number after the same publisher's latest release but I myself couldn't find any source, it later turned out to be wrong.
Secret Squirrel
Mar 21, 2010, 05:16 AM
I would make all of that be handled by the database, i.e. turn the usually alphabetical part into an enum, give separate text fields for entering the first and (if it is a multipart product) last item's number. Then showing the number in a correct way can be handled automatically, and the amount of digits (non-used filled with leading zeros) as well as choosing the separator can be made dependent on the publisher or easily changed globally.
That's a thought. You could probably make it less complicated for the submitter by just parsing the catalog number string based on who the publisher is.
Do you think we ever need an instruction message like "Please don't guess the catalog number even when it's too obvious for you"? I don't think so many submitters do that, but for some smaller vendors it's certainly easy to predict what comes next, and in one of the few cases where I saw people adding the next catalog number after the same publisher's latest release but I myself couldn't find any source, it later turned out to be wrong.
I didn't know this was happening so often. Maybe we need to add "Please don't guess the catalog number for upcoming releases."
seanne
Mar 21, 2010, 07:48 AM
More explanation about when to ignore the formatting of the Catalog number on the obi
What kind of situations are you thinking about here?
Should we keep replacing spaces with dashes in the LC-* series?
Not sure if the LC stem has been discussed before, but why make a special exception from our standardization for this one in particular?
Secret Squirrel
Mar 22, 2010, 05:35 AM
Yeah, we had a discussion about this in one of the album threads. The question was whether we are replacing all spaces with dashes, or whether we were more selective about it.
This big examples are KICA, NACL, and AZCA. None of these publishers use hyphens on the Obi, and in some cases (King Records example (http://vgmdb.net/db/covers.php?do=view&cover=44688)), they don't use them when the catalog number is printed on the back. Based on these examples, we decided that we were following the formatting based on the official website, which in all these cases includes a dash instead of a space.
However, the Konamistyle releases seem to be an exception. (http://www.konamistyle.jp/ecitem/item64440.html) The official site just simply deletes the space instead of replacing it with anything.
One caveat: if most other sites (http://game.musicrelease.info/data/2005/200509.htm) use a different form of the catalog numbers, whether that be hyphenated or not, then our album pages won't come up in the searches, unless we start listing permutations of catalog numbers.
Ira
Mar 22, 2010, 10:27 AM
However, the Konamistyle releases seem to be an exception. (http://www.konamistyle.jp/ecitem/item64440.html) The official site just simply deletes the space instead of replacing it with anything.
The LC catalog numbers have no separator (space or otherwise) when printed online or on albums (based upon what scans I've seen, there might be some exception I'm not aware of.)
Secret Squirrel
Mar 22, 2010, 10:58 AM
Oh, I thought I'd seen them with a space somewhere. Taking a look at some obis, it looks like they insert a carriage return in between LC and the number, but everywhere else there is no separator.
The overall question though is whether we are going with the idea that most cat numbers have a specific format, which is
STEM-NUMBER~MULTIDISC
and we've already agreed that:
The multiple disc separator is always "~"
MULTIDISC always has minimum repetition
NUMBER may get an extra zero if it was added later in the catnum run
even if this differs from the obi, cover, and official number on the website. So, should we just extend this to the cover the STEM and the first separator?
Note that some catalog numbers differ from the format above.
Dag
Mar 22, 2010, 11:02 AM
I'm with Datschge, let the db handle it. Just input whatever is printed and have the site show it how it fits better. Though really, why do catalogs need to be prepend/fixed if the publishers themselves can't keep their numbers straight...
Secret Squirrel
Mar 22, 2010, 11:23 AM
Though really, why do catalogs need to be prepend/fixed if the publishers themselves can't keep their numbers straight...
Simply so that they sort nice.
I can't think of any specific examples where we prepend the zeros, but I'm pretty sure that it hass been done.
seanne
Mar 22, 2010, 05:17 PM
About KICA, they've used both KICANUMBER, KICA NUMBER and KICA-NUMBER, seemingly at random. As Ira said, LC seems to always be listed without any separator, but I don't know if it can be considered enough of a conscious choice on their part for us to go with it. I for one always liked the idea of basically going strictly with STEM-NUMBER(~NUMBER) since it makes things sort nicely and look neat.
And I think it's always better to go with what's on the spine than on the obi since it tends to be on two lines there.
Gigablah
Mar 22, 2010, 05:51 PM
I'll throw this post here:
http://vgmdb.net/forums/showthread.php?p=7678#post7678
It should be noted that Wave Master is not consistent with how they write their own catalogue numbers.
For example:
Golden Axe The Music (http://vgmdb.net/album/6203) is WM-0595~0597
AFTER BURNER 20th Anniversary Box (http://vgmdb.net/album/4992) is WM-0581~86
MONSTER WORLD COMPLETE COLLECTION ORIGINAL SOUND TRACK (http://vgmdb.net/album/4437) is WM-0565~6
I'd recommend we follow the standard of only having changed numbers after the tilde.
We could change the policy so that we follow what's written on the obi, but keep in mind that if we do so, we'd have to be consistent across all entries in our database. This means going over all previous entries to account for variations such as the ones I've listed.
(Another possible solution is to have an optional "catalog variation" field, like how artist name variations are handled)
Cedille
Mar 22, 2010, 07:34 PM
I didn't know this was happening so often. Maybe we need to add "Please don't guess the catalog number for upcoming releases."Well, I didn't intend to say it happened often. Given my limited data gathering ability, it's arrogant of me to say people speculate the catalog numbers just because I can't find any evidence, and even in the case which turned out to be wrong the publisher might have changed the number from the initial announcement. However, I still sometimes have to wonder where this number comes from in or outside of VGMdb (...another reason why I'm not terribly up for this is because the line between guessing and logical thinking can be seen as fine. Do we have a problem with adding Square Enix as the publisher, when a new album with the SQEX stem but no publisher information is added by casual submitters?).
Yeah, we had a discussion about this in one of the album threads.
I think it's here (http://vgmdb.net/forums/showthread.php?t=271).
With regard to the LC- stem, I'm not sure if we should be picky about the hyphen in particular, when Konami also has a different policy for the number repetition.
Ira
Mar 22, 2010, 08:02 PM
I for one always liked the idea of basically going strictly with STEM-NUMBER(~NUMBER) since it makes things sort nicely and look neat.
I'm not at all opposed to this, the issue that has been brought up is that we would need to start listing permutations of catalog numbers.
With regard to the LC- stem, I'm not sure if we should be picky about the hyphen in particular, when Konami also has a different policy for the number repetition.
This is true, we don't, which creates an issue with searching similar to the one that has been brought up (only effects multidisc albums though, and searching for the first part of the catalog number works.) So, the question is do we want to make '[STEM]-[CAT#]' the standard formatting for catalog numbers? If yes, we should keep LC the way it is, if no they should be fixed.
Secret Squirrel
Mar 23, 2010, 08:49 AM
Do we have a problem with adding Square Enix as the publisher, when a new album with the SQEX stem but no publisher information is added by casual submitters?).
I guess that technically we should be careful about this as well. I think that in most cases, the publisher is pretty clear, but the distributor might not be known until someone posts the Obi or Back scan.
This is true, we don't, which creates an issue with searching similar to the one that has been brought up (only effects multidisc albums though, and searching for the first part of the catalog number works.) So, the question is do we want to make '[STEM]-[CAT#]' the standard formatting for catalog numbers? If yes, we should keep LC the way it is, if no they should be fixed.
It seems like we're leaning towards this, though perhaps some of these things should be resolved with a vote.
By the way, now that each disc has its own catalog number, I need to work on a way to incorporate these into the search, so that you can search on the second disc's catalog number and still find the album. One way to do it is to cache all of the disc catalog numbers in the album table. The other is to modify the searches to join with the media table, but I don't know how much overhead that would incur.
Cedille
Mar 24, 2010, 09:59 PM
I guess that technically we should be careful about this as well. I think that in most cases, the publisher is pretty clear, but the distributor might not be known until someone posts the Obi or Back scan.
Yeah, if I were to guess (or detect, if it sounds better) the organization behind the catalog stem, it'd be normally only the publisher, and I tend to wait for the Obi or a few websites that don't mix up the publisher and distributor, though I know anything with the SQEX and KDSD stem is linked to Sony Music Distribution once it's added (not that I have an issue with this, as the distributor info on them can't generally found on the booklet, and I also linked SuperSweep to every BSPE album according to this blog post (http://www.sweeprecord.com/?p=621)). I still think guessing the catalog number is another thing, but it can be called double standard.
Unless we have an opportunity to discuss about this later, may I ask if there is something wrong with adding the distributor to the publisher field? I think we tend to avoid or sometimes erase that, if it's explicitly denoted as the distributor (like [distributed by...]) but it's useful if we can search albums by distributors and I think not every catalog stem belongs to only publishers.
Secret Squirrel
Mar 25, 2010, 03:32 AM
Unless we have an opportunity to discuss about this later, may I ask if there is something wrong with adding the distributor to the publisher field? I think we tend to avoid or sometimes erase that, if it's explicitly denoted as the distributor (like [distributed by...]) but it's useful if we can search albums by distributors and I think not every catalog stem belongs to only publishers.
I'm not sure what you mean. I always add the distributor to the field, if I know it. I do it like this:
### (distributed by ###)
The "distributed by" is wordy and probably not needed if we can come up with a better syntax that implies it.
Cedille
Mar 25, 2010, 06:04 AM
I'm not sure what you mean. I always add the distributor to the field, if I know it.
I remember the distributor info submitted by users was removed multiple times, so I thought other members might have a different stance (or perhaps it was just a wrong distributor :tpg:).
Secret Squirrel
Mar 25, 2010, 06:34 AM
You might be thinking of cases where (distributed by iTunes) was added, but the album was sold by iTunes, Amazon, and a couple others, so it wasn't clear that we would be able to differentiate in our system without having a separate album for all of those. (We've got much to discuss about digital releases, since the current system is really geared for physical releases.)
Ira
Mar 25, 2010, 06:40 AM
You might be thinking of cases where (distributed by iTunes) was added, but the album was sold by iTunes, Amazon, and a couple others, so it wasn't clear that we would be able to differentiate in our system without having a separate album for all of those. (We've got much to discuss about digital releases, since the current system is really geared for physical releases.)
Yeah, I've been wondering about this myself. It seems kind of redundant to add multiple albums but at the same time, there's not really any other clear way to do it. Also not sure how digital singles should be handled.
Cedille
Mar 25, 2010, 08:23 AM
You might be thinking of cases where (distributed by iTunes) was added, but the album was sold by iTunes, Amazon, and a couple others, so it wasn't clear that we would be able to differentiate in our system without having a separate album for all of those. (We've got much to discuss about digital releases, since the current system is really geared for physical releases.)
One of the cases was surely iTunes Store (and the entry was actually linked to iTunes Store), but others not. Anyway, my intention was to know if we were allowed to add Imprint/Distributor to the publisher field (which I thought wasn't so common) rather than to criticize specific edits. I'll probably edit existing entries from now on.
And yeah, I also stopped adding digital reprints for the very same reason unless there are something exclusive. It sometimes has to be a separate entry when the displayed track lengths are different from those of the physical entry.
vBulletin® v3.8.5, Copyright ©2000-2013, Jelsoft Enterprises Ltd.