Hacker News Reader

Comment by dawnerd | Hacker News Reader

It's worse if you're ripping foreign audio. I got a bunch of discs from Japan which I would assume, being Japan and all, there would be excellent data online. Wrong. Every single album got matched to something else.

Even accurip was incorrect. I pretty much don't trust any of the online data sources anymore and just manually enter meta.

And don't do what I did... don't just lets beets run unattended. What a pain that was.

View on HN

I was doing audio + metadata ingestion for the major labels and they sent us a truck load of East Asian CDs of different languages, and here's me with a team of poor minimum wage high school grads looking at me all crazy.

Yes, you're right. Also, with obscure or rare CDs. If they're in the databases at all, the odds are better than 50% that the data is incorrect to some degree, or they are confused with completely different albums.

Isn't that still a labor-saving starting point?

the problem with false positives is that a single instance means you have to review every record meticulously, because you have no idea where the system has lied to you, or how many times (because the system itself doesn't). If you're going to review everything anyways, it's often better to simply be slow and correct to begin with rather than diff and correct every item.

this is why it's usually better to be overaggressive with saying "I don't know" rather than crossing your fingers and shitting out an answer and hoping you get away with it.

When did we switch the conversation to LLM issues? =)

One of the devs for a company I used to work shocked me when he said "bad data is better than no data" when inquiring about why the input field was limited to a drop down of pre-filled values that were irrelevant with no way of filling in correct data. At that point, I just felt the entire database was suspect

Often not, because it's less effort to type the information in fresh than to review and edit the existing information.

I'm not saying the services are always overly incorrect, just that they're incorrect often enough that the path of least resistance was to stop using them.

Plus, it gave me something to do while the CD was importing rather than just pushing into the background while I started working on something else and promptly forget about the import.

Depends how long it takes you to figure out what the problems are and fixing them.

Debugging is usually harder than coding, and the amount of data we are talking about is fairly small. Just typing it in could easily be faster.

It depends. I'd like to argue that you have to enter the information one way or another, why not share it and save others the work in the future, but in reality it is often quite a bit slower. MusicBrainz likes to collect more information than a normal CD riper would ask for, with more pages to click-through, so that is a bit slower. However, the main annoyance is when you have to make a correction that isn't auto approved, and then you have to wait 7 days before your tagger/ripper software will see changes you made. I wish there was a better workflow to tell Picard to use a pending edit[1].

I still always use MusicBrainz, and enjoy contributing to it, but more like others enjoy contributing to Wikipedia, rather than as an efficiency boost.

[1]https://tickets.metabrainz.org/browse/PICARD-1278

your best shout for jp cds is hoping someone added them on discogs

I think about half of the Japanese albums I tag have a mistake of some sort on Discogs, such as wrong okurigana or kanji usage. I've corrected some of them myself, but it happens so often that I've mostly given up. In the end it's faster to transcribe from the back cover.

Reply on news.ycombinator.com