Live data from Hacker News

The music classifying nightmare

blog.pkh.me

31–40 of 77 posts

Re: The music classifying nightmare

#31

Somewhat related but as I've been building a rails project I've been meaning to open source the song parser I've been building alongside it. It scans an mp3 and pulls out the artists along with the type of role they played on the song. Here's a quick gist I pulled from my model: https://gist.github.com/3680949 Some examples: Drake - The Motto (Jon Bellion Cover) => [["Jon Bellion", :cover], ["Drake", :original]] Davi…

This looks awesome. You should consider sticking it somewhere and giving it a name, so that I might find it 6 months from now when I'm motivated to fix my shitty Python script [1].

Also, a side question: is it normal/considered a best practice in ruby to monkey-patch built-in libraries like that? I know ruby has open classes, but I'm just curious how using them in this way is regarded.

[1]: http://news.ycombinator.com/item?id=4494437

Re: The music classifying nightmare

#33
post #31

Somewhat related but as I've been building a rails project I've been meaning to open source the song parser I've been building alongside it. It scans an mp3 and pulls out the artists along with the type of role they played on the song. Here's a quick gist I pulled from my model: https://gist.github.com/3680949 Some examples: Drake - The Motto (Jon Bellion Cover) => [["Jon Bellion", :cover], ["Drake", :original]] Davi…

This looks awesome. You should consider sticking it somewhere and giving it a name, so that I might find it 6 months from now when I'm motivated to fix my shitty Python script [1]. Also, a side question: is it normal/considered a best practice in ruby to monkey-patch built-in libraries like that? I know ruby has open classes, but I'm just curious how using them in this way is regarded. [1]: http://news.ycombinator.co…

I put the link to the gist with the code for now, when I get a couple hours free sometime (soon I promise) I will do just that and put it on my github, so feel free to watch my account there.

As for patching string.rb I don't know 100% but I believe thats the point of being full OO is that I can make a patch like that where it makes sense to do it. I was using those functions in multiple places, and given they are meant for strings it made sense. I can see the potential pitfalls when it comes to sharing things like this, but again, Ruby makes it easy for anyone to make the same patch for a reason.

Re: The music classifying nightmare

#35
post #30

I only go so far as sanitizing and standardizing my music collection through Tag&Rename (and I haven't found a good OSX equivalent to this yet sadly). It gets the data from Amazon in 98% of cases, adds the album art (which I like having on my player), etc. Then I store the files in: Artist/Album/Track# - Song name [- Artist name] The last is only there for soundtracks and other "Various Artists" type collections. Thi…

I'm not sure how much of this is conjecture. My thinking differs from yours with respect to the following -

"Albums don't really have years either. Or at least they have publication years. The songs have years. Normal studio albums have a common year. Compilations and soundtracks do not."

An album that is released by a record label does have a year, as upon release it becomes a publication. By this train of thinking i would also say a soundtrack does have a year, too, as it is published as a collection timely to the context of its release. The same can be said of compilations, as they are a contemporary release.

Re: The music classifying nightmare

#36
post #26
post #4

Earlier quoted context omitted.

It's not irrelevant. If the exact same recording of a song appears on two albums, an ideal categorization system would allow it to appear as such without storing multiple (redundant) copies of the song. An easy way to think of it is a normalized relational database. If the song has an id of 5 and is on two albums with id 2 and 3, then there would be an AlbumSong join table with schema (album_id, song_id) and two rows…

Why do you care about this? When you listen to the album, you obviously want to hear every song on the album, and hard drives now are so big (and this occurence rare enough) that the extra space can hardly matter. So why do you care?

Obviously, it's not a huge problem. Like the author of this article, I am just annoyed at how difficult it is to conceive of and maintain a perfectly organized music collection. As for your specific question, however, it would be trivial to query your collection like SELECT * FROM songs WHERE song.album_id = 2, which would get all the songs on that album even if one of those songs is also part of album 3.

Re: The music classifying nightmare

#37
post #30

I only go so far as sanitizing and standardizing my music collection through Tag&Rename (and I haven't found a good OSX equivalent to this yet sadly). It gets the data from Amazon in 98% of cases, adds the album art (which I like having on my player), etc. Then I store the files in: Artist/Album/Track# - Song name [- Artist name] The last is only there for soundtracks and other "Various Artists" type collections. Thi…

Yeah. Music is classifiable in some sense, but its a hugely complex and multi-directional thing and most 'classifications' really just scratch the surface. And while algorithmic recommendation services (lastfm, spotify, etc.) can be nice for a while, actually people are complex and always change their views and interests, so they are never always going to give you what you want.

Personally for my own collection - I have a loosely interpreted directory structure that I've evolved that is basically 'continent and/or genre'/'artist'/'album (with year recorded at the start if I have lots of them)' that works well for me and I don't have to constantly rename everything I download (theres some less-sorted directories of things I don't listen to much within this).

For searching, tagging and playing I use foobar2000 (unfortunately still windows-only) because it has plenty plugins which handle everything from tagging (eg. from discogs and freedb), through to searching (keeps a constantly updated and strongly index media library, which can be searched from a range of front-end UIs) and information finding (getting album covers, lyrics, artist biographies, etc. and displaying as you like). I don't do lots of retagging, but I do find it useful sometimes - for instance I have tagged some of my more listened classical music by composer and performer separately, so I can look at it from either direction when I want to.

Re: The music classifying nightmare

#38
post #6
post #4

Earlier quoted context omitted.

It's not irrelevant. If the exact same recording of a song appears on two albums, an ideal categorization system would allow it to appear as such without storing multiple (redundant) copies of the song. An easy way to think of it is a normalized relational database. If the song has an id of 5 and is on two albums with id 2 and 3, then there would be an AlbumSong join table with schema (album_id, song_id) and two rows…

I wonder how often a bit exact copy of one song appears... Sure the songs might have the same title and duration, but some very trivial edits might be done. You need to be extra careful when identifying these songs as identical if you don't want to lose any information. Of course, from a listener point of view it might not mean much, but how would you decide at which level of non-similarity a track is the same as ano…

You bring up an interesting point: the identity function for a song is not self-evident. Even if two versions of a song are from the exact same recording and mastering, one could have a bit of extra silence at the end, or if they're lossy encodings, different encoders or bitrates would yield different files. What I said would only work with songs that are declared to be identical, however you choose to do that.

Re: The music classifying nightmare

#39
post #10
post #4

Earlier quoted context omitted.

It's not irrelevant. If the exact same recording of a song appears on two albums, an ideal categorization system would allow it to appear as such without storing multiple (redundant) copies of the song. An easy way to think of it is a normalized relational database. If the song has an id of 5 and is on two albums with id 2 and 3, then there would be an AlbumSong join table with schema (album_id, song_id) and two rows…

> If the exact same recording of a song appears on two > albums, an ideal categorization system would allow it to > appear as such without storing multiple (redundant) copies > of the song. I don't agree. The song was released twice; if you have both albums, you ought to have two copies of it.

Yeah, it's not going to be a big storage hit in reality (and even if it were, you could just rely on file system level compression/deduplication). I, like the author, just enjoy musing about the "perfect" way to organize a music library.

Re: The music classifying nightmare

#40
post #22
post #15

You're making the problem a lot harder than it needs, or ought, to be. The most telling example, IMO, is the Aphex Twin one... > Oh, and his real name is Richard David James. What are you > supposed to use for the file system directories and files > name? His name? The most common nickname? Both? One file > system solution is to have symbolic links (do you link > Richard David James to Aphex Twin, or vice versa?). Fo…

Well, it's the same person behind. Even if the artist tried to give a different "personality" to his music over the time, following all his creations is actually a good listening experience. The "hey I just want to listen to the musical evolution of this guy" isn't a rare feeling IMO. Grabbing all his nicknames is kind of a problem. Of course, you have a point, I'm making the problem harder than it needs, and you can…

But that's not a problem, either. In my music collection I have, e.g. tags ARTIST=AFX and FILED_UNDER=Aphex Twin. Then when you make a playlist with your favorite music player, you can just sort things by FILED_UNDER, if you prefer. What's so hard about that?
Post reply on HN