Slashdot Mirror
Cultured Perl: Fun with MP3 and Perl, Part 1
Ted writes "Every self-respecting computer and music fan needs to be able to manipulate MP3s -- the defacto standard for recreational digital music use. In this article, I'll look at ways to manage and manipulate MP3s (searching, tagging, renaming, commenting, etc.) using the autotag.pl application. I'll also take you through the application, illustrating how CPAN modules enable the application."
The Army reading list
It's nice to know you can do this, and I've used the modules referenced for custom fixes. But don't reinvent the wheel if you don't have to: EasyTag probably does 90% of what you would write something custom for.
here you go:
An object-oriented interface to Ogg Vorbis information and comment fields, implemented entirely in Perl.
I just don't trust anything that bleeds for five days and doesn't die.
Right here. Or here for FLAC.
Josh
FLAC - Free Lossless Audio Codec
ID3v1 tagged before the MP3 stream. ID3v2 tagged behind the MP3 stream.
Actually, you're wrong. ID3v1 placed it's tags in an MP3 file by appending 128 bytes to the end of the file. ID3v2 inserts its tags at the beginning of the file.
The only reason for that was that you couldnt add anything more to the beggining of the stream, unless you broke backwards compatibility. The first (?)128 bytes were assigned for the ID3v1 tag, in the initial MP3 standard, when ID3v2 was designed, adding it to the end of the ID3v1 tag would have resulted in nastly click's and pop's, when an older player didn't understand it. When it was added to the end, past the end of the track, it retained backwards compatibility (without ugly pop's), and allowed unlimited storage of additional data. ID3v2 is scalable enough, that if ID3v3 is realised for some god-foresaken purpose, it could be fitted on the end, without any future problems.
That being said. Foresight that people would need more than what ID3v1 offered shouldnt have been too difficult to muster, an extra forced 256b surely wouldnt extend everyones downloads by too much.
-Adam
#!/bin/csh cat $0
To be fair, the MusicBrainz article for perl.com (that, full disclosure time, I wrote) doesn't cover as much ground as the Developer Works article, which seems to be going through all the steps needed to write an autotagger in Perl.
However, I was a little dissapointed that Teodor didn't spell out more of his reasoning for his choice of modules. I covered the (then) available Perl mp3 modules for a talk at YAPC::Europe this summer, and if you're not sure which modules to use, I'd suggest having a look at the slides (80K PDF) and notes.
In any case, I look forward to the second part of the article, to see how the script shakes out in the end.
DO NOT LEAVE IT IS NOT REAL
Generally, CDs don't have all the track information on the CD. RealPlayer, Windows Media, iTunes and so on all use a computed identifier of some sort, based on the length of tracks, typically, to look up the CD information from an online database.
Of course, because this means that *someone*, *somewhere*, ended up typing in the data, there are errors in a lot of the data. Most of the CD lookup databases are very bad at handling compiliations, and can have problems with any of the items of metadata other than title and artist (for example, 'year' often ends up as the year the CD is ripped, not the year the music was produced).
There aren't many programs that strip the data that's produced, though. Thankfully.
DO NOT LEAVE IT IS NOT REAL
You're referring to CD-TEXT, a standard of sorts introduced by Sony where Artist, Album name, and track titles are encoded onto an audio CD in the subcodes.
It's true, not every commercial pressed CD out there has this feature, and believe it or not, not every CD-ROM (particularly older ones) can read the subcodes to extract the CD-TEXT info.
Sony Music includes CD-TEXT on all the CDs in it's catalog (to complement the CD-TEXT display features on most of it's car CD players.) I don't know about the other major labels.
My own experience with small labels tends to indicate they're not large users of CD-TEXT, but you can find the odd release which does have it.
Besides, I will not tolerate ANY DRM in my music files.
By "weird itunes format", I assume you're referring to the AAC MPEG4 format, which is an industry standard.
Also, there's only DRM in files that you buy from iTunes Music store. Please stop spreading the FUD that "AAC == DRM", because it's simply not true. Just like "EXE file" does not translate to "software which needs a registration key" and "VHS tape" does not translate to "protected by Macrovision". AAC is an open MPEG4 format to which DRM _CAN_ be applied. By default, it is not applied.
Also, what do you mean by "A2D" converter? Why would an MP3 player, which decodes digital signals into analog signals which your ear can hear need an "analog to digital to converter"?
There is no sig, there is only Zuul.
30 seconds with google revealed, among several MP3 player modes, this MP3 tag editor mode for emacs, released in 1999. Next question?
Okay, then, what about ML? There are several high-quality native-code implementations, including SML/NJ and OCaml. It uses static rather than dynamic typing, but the compilers infer the types of most variables for you, so you rarely have to declare any types, and this approach also means you know about any typing errors at compile time.
:p
With OCaml in particular you get most of the speed of C, and most of the convenience of a dynamic language, in one package. And if you want to use C libraries, there's a rather nice FFI. If you want to call Perl code, guess what? You can.
Hmm... maybe I'm overdoing the advocacy a bit here... but anyway, Lisp is obsolete, 'cause ML does most of the same stuff and has human-readable syntax to boot.