the zeros in CatNr's

[hanswurst]

according to many corrections about the real etchings and the CatNr's displayed in the database i started this topic. In case there is already a thread about this issue plz delete it and bump the existing one (my poor english brought me no results in the forumsearch).

 

i also prefer the ?standardisized? CatNrs because it gives a better overview in the frontend and i am sure there are a lot of users who also prefer this. On the other hand it really makes no sense that a search for the correct etching gives no results. Further sometimes there are discrepancies between the CatNr on label-stickers and vinyl-sleeves and etching! The best database design is to have the possibility for a unlimited amount of values for a single attribute. (as far as i know the database design allows also only 2 featured artists at the moment).

 

Best thing for making all users happy would be to store both(all, in case there are more) CatNrs in the database and the user has the possibility to choose between the correct and the standard version.

What do you guys think about? Are there any others who prefer the incorrect version?

[Phokus]

We use the etched catalogue number. Errors creep in if we don't physically have a copy of the record in front of us, in which case we have to rely on second hand information or on label scans... so if the label information is wrong, the info that goes into the database is also wrong until someone corrects us.

[haste]

I'm pretty sure the database does store two versions of the cat no if there are differences between the etched and printed ones. It only displays one (the etched version) but the search should bring up results for printed cat nos that are different. We won't be standardising them, though. There's no point in making things look nice if that's not what the cat nos of the release actually are, we're only going to record what is on the actual vinyl, even if it does make the listings look a little messier.

 

Like you say, what's the point in fudging the cat nos of a release if the user then can't find it using the search?

[Phokus]

yeah, there is a second entry should the printed version differ.

[Cob]

Any plans to display both the etched and printed cat number on the release screen? I know searching for both of them will bring up the correct release but would be a good feature to show both.

[haste]

Yeah, that shouldn't be a prob at all

[hanswurst]

....We won't be standardising them, though.....

 

But artist and title is standardised. That is what i love on rdb!!!

I think there is no chance to store the unstandardised version of each field. Have you ever thought about redesign the database with only one attributes-table which would allow unlimited values for each field?

 

for example (i don't have a good example right now but i know there are a lot of releases with differences on sleeve/sticker/rdb-entry):

http://www.rolldabeats.com/release/moving_shadow/shadow41r

http://www.discogs.com/release/29875

 

Sleeve credits Y track as 'Fantasy 3.1'

record itself says 'Fantasy #2'

rdb-standardised version: 'Fantasy #3.1'

 

 

i am sure that thousands of db-entries have spelling differences in artist and title field...

(currently i am working on a db design with only one attributes table for everything, but without nested sets)

[haste]

Standardising stuff is a dangerous game to play. We have done it before and, in my opinion, it got way out of control and some changes that shouldn't have been made were made.

 

In cases like above then we should just go with what makes the most sense as we can't easily list two track names for one tune. I have no idea if what we have listed is even the best track name in this instance. If it's a remix of Fantasy #2 then I would have thought it more sensible to call it that rather than anything else.

 

In terms of cat nos this is different. If i'm understanding your point correctly you might be referring to a release on a mythical label represented here

 

CAT001

CAT002

CAT003

 

this would be the standardised listing yet the reality is that CAT002 is actually etched CAT2 and the label has CATT02 printed on it. In RDB only the etched and printed versions would be recorded even if it makes the listing look untidy. We are not here to fix people's mistakes when it comes to catalogue numbers and if you knew the extent of the headache we have had with some labels then you would probably stick with us on this.

 

If the cats look untidy then they'll continue to do so. We will not make up cat nos that do not exist and list them for this purpose.

 

ps yes we have thought about a database design that allows unlimited cat nos for a release and this will be one of the things that the planned db redesign allows (among many other things that need changing). However, finding someone to take on this huge job and then finding someone to pay for it is no small task.

[FuZion]

I'm down with the RDB crew on this one.

 

I used to standardise my own little local database & when searching for them I had to revert to the original. It didn't take me long to realise it was a bad idea. In fact, due to the comprehensive way the RDB database it stored, it's easy enough to find tracks via label, artist, track etc...

 

I do like the idea of having an etched & printed version of the Cat numbers though because they do get a little mixed up at the time of printing/pressing at times. Maybe a 'third' stardardised version could be an option but it throws up a couple of potential problems. Clashing with others actual Cat No's & of course the fact that there's thousands of releases on here & there's have to be some slinky script built to be able to recognise all the different variants of Cat No's to standardise them. Manually doing it would take so much man power when, IMO, there's other things that could be prioritised.

 

FuZion.

[geist]

if I ever notice that there are more zeroes in the etched cat#'s on vinyls, I include it in a 'corrections' post under releases

 

it does get confusing though because labels will print cat#'s without zeroes on the sleeve, then etch them with the zeroes, etc

 

it is a somewhat regular occurence for me to search for something in the database based on the etching, which has zeroes, and the search does NOT hit upon the intended release. I have to search for the 'non-zero' cat # version to find this release. Sometimes a search for either version of the cat # hits upon the release, but not always

 

I'm generally opposed to 'corrective' cat# additions. I think it just makes things worse as well. But sometimes there are issues where making a new cat# is a necessity (like if a cat# does not exist, or if there are different releases from promo to full release on that cat#, etc)

[haste]

I'm sure we've been over this before...?

 

There are two cat nos stored in the db. One (the one that shows) is the etched cat no, the other (at the moment not displayed) is one used, usually, for the printed cat if it is different. You should be able to search for the hidden variables but I cannot show you an example as I don't have access to the data.

 

If you are getting the same release appearing on searches for two cat nos and other releases not showing when searching for one of the cats then it would suggest that there are some releases that don't have both cats entered into the db.

 

We do make up cat nos if there is none and also do append cats if there are different promo or TP releases, this has been done this way for a long time

[Phokus]

Plus it is worth bearing in mind that I don't actually have access to the vinyl for 99% of the releases that go in to the database, so I rely on listings etc for the catalogue numbers.

[Ornette]

if I ever notice that there are more zeroes in the etched cat#'s on vinyls, I include it in a 'corrections' post under releases

 

Cat numbers, something that 'uniquely' identifies records (well, is supposed to at least) should defo in my opinion be added in to database as appears on the vinyl. I think this has always been the approach with cat numbers here. If there are more, or less 0's on a given release than currently listed in the database I would agree that a correction should be made.

 

However, to address other concerns, what I understand is that there is a custom order criteria that Thijs developed that has ability to force label listings into the correct order, no matter what un-orthodox method each cat number follows from release to release. A good example is the Brain Records label

 

The first 11 or so cat numbers are silly! yet, the database manages to reflect them in the correct order as they were released.

 

So 'standardising' cat numbers here is not really an issue. However it does then take effort for someone to take note of what should be the correct order and then get that custom sort index correct.

 

What RDB doesn't do, and something I think would be the completing touch to this issue, is to have a search engine that could parse through 0's in cat numbers. The search engine on RDB at the moment does a good job of parsing cat numbers, much better than Discogs, but I don't think it is able to deal very well with 0's and matching to entries that may have less or more 0's in the field.

 

 

One thing that RDB does do to standardise cat numbers is is to disregard spaces & hyphens in cat numbers, and standardises to a basic truncicated alphanumeric form. This I think is the sensible approach.

[haste]

What RDB doesn't do, and something I think would be the completing touch to this issue, is to have a search engine that could parse through 0's in cat numbers. The search engine on RDB at the moment does a good job of parsing cat numbers, much better than Discogs, but I don't think it is able to deal very well with 0's and matching to entries that may have less or more 0's in the field.

The search can do this already. You can use wildcards in any search which offers much greater power for querying cat numbers. I would never suggest the search ignore 0s as it would return far more results than you might need. I hate the Discogs search as it returns so much that I know I don't want, especially when seraching cats.

 

in RDB a search for ABC001 will only find that but ABC*1 would find ABC001, ABC01 and ABC1 etc. Making the search ignore zeroes would probably give you all these results each time you searched which is useless imo

[Ornette]

in RDB a search for ABC001 will only find that but ABC*1 would find ABC001, ABC01 and ABC1 etc. Making the search ignore zeroes would probably give you all these results each time you searched which is useless imo

 

Ahh I didn't know it could do that :cool: that sounds perfect

[haste]

Yup, you can use wildcards for any type of search. This makes it a lot more powerful than usual, assuming people know they can use it!