Hello Monks.
I've been toying with the idea of a new MP3::* module, MP3::UNC, or "Uniform Naming Convention". I'm getting to the point where I can release an 0.5 version of it. Here's the pod, I'll follow with some comments.
=head1 DESCRIPTION
Intended to take MP3 files following a unified naming convention (henc
+e the
UNC monniker) and provide object oriented methods for organizing them
+into
genres and playlists. Both an extended playlist included genres and ex
+tended
track information as well as a standard, filename-based .m3u format. A
+dding
support for additional playlist formats (such as gqmpeg or iTunes) sho
+uld be
mostly trivial. Some filename conversions would be necessary. These ar
+e not
supported as no need (read: demand) has been seen for such additional
functionality.
=head1 CONVENTION
Anyone who has spent time downloading MP3's is aware of the mass dispa
+rity
in how files are named. This is partly due to there being many differe
+nt
platforms which can encode MP3 files, but also due to the fact that th
+ere are
also many different pieces of software that can encode. As if that wer
+ent
enough, there is also a difference in preference among users of the fi
+les for
they want their files to be named. After a brief survey of both my fil
+es,
the files available for download, and the general output of programs
available, I determined that the most widely used format (which also
happened to contain all the necessary information for these procedures
+ to be
implemented) was the following:
Artist - Album - Track Number - Track Title.mp3
This module does not care whether you name them .mp3 or .MP3. Case is
+of
course important since UNIX is case-sensitive. Mac and Windows machine
+s
should not have problems with case since they are not case sensitive.
+The
function that parses filenames into the hash format is mostly an OO wr
+apper
around this statement:
my @fields = split / - /, $filename, 4;
With this statement, it makes it possible for the track title (but not
+ the
album title nor artist) to contain the ' - ' string. Thusly:
# this will work
Ween - Chocolate and Cheese - 13 - Buenas Tardes Amigo.mp3
# this will not
The Barney - Love Brigade - You and Me - 01 - I love you.mp3
Please note that single digit numbers are prefixed with a 0. While thi
+s
doesnt have a 'real' purpose, per se, it does provide some pretty form
+atting
advantages:
# a sample .m3u list
# look mom, all the filenames line up:
Ween - Chocolate and Cheese - 01 - Take Me Away.mp3
Ween - Chocolate and Cheese - 02 - Spinal Meningitis (Got Me Down).m
+p3
Ween - Chocolate and Cheese - 03 - Freedom of '76.mp3
# ...
Ween - Chocolate and Cheese - 11 - Joppa Road.mp3
Ween - Chocolate and Cheese - 12 - Candi.mp3
Ween - Chocolate and Cheese - 13 - Buenas Tardes Amigo.mp3
Since this doesnt hurt anything and it does have the one nice benefit
(and several encoders produce it), I am inclined to keep it in the
convention laid out in this module.
I have decided to be pretty unforgiving as far as data being malformat
+ted.
It is my hope that being rigorous about the naming convention will lea
+d to
easier file portability from one machine to the next. Please see the s
+ection
on error reporting below for further information.
So here's what I think... There is a major benefit to this. If I produce a module that creates new, far simpler and more modular ways to do things, it will probably simplify the life of anyone who wants to automate their mp3 collection. I suspect that I can convince several authors of encoding/ripping software to include a "UNC" tag in their software so that it would be pretty easy to start unifying at least the unix mp3 encoders out there (such as myself).
Ill get into the main reason for this post in a minute, but first I want to explain why I think this is cool.
Lets say you have 5,000 mp3 files. Lets say you have also gone to exceptional trouble to name them. Or, perhaps (such as in my case), most of them are named according to one convention. If you were to then use streaming software or archival software or burning software, it would be exceptionally easy to move them around as discs, genres, playlists, artists, and so on. While its possible to do this with independant scripts and shell commands, who the heck wants to?? Lets face it. Bandwidth and disks arent getting any smaller. This leads me to my next point.
Sure I'd like to be the next Microsoft! well.... perhaps that was too attention-getting. What I started to see here, as I was writing this module, is I could switch it around and make it UNC::MP3. This hit me while I was talking to my boss about these Crystallography files we get from scientists that are all named differently. Why not create a UNC parent class, and start defining sensible naming conventions for files that dont already have them?
imagine:
- We're going to start seeing whole dvd's traded even more than they are now. It will save the unix community a lot of trouble if we have a uniform naming convention _before_ that happens.
- If you have something, like Crystallography files, that are all named differently, it would not be very hard to hack out a module and suggest to your users that they follow the convention.
- Unified Naming Conventions allow us to classify files which normally defy classification by providing us with all of perl's flexibility. You dont need to say this is a Foo file, you can say it is a UNC::Foo file that belongs to [ bar, baz, bletch ] families. You can then map and chart and move and whatever you want with UNC::Foo files with an OO interface.
I dunno about you guys, but I find this to be very cool. My concern though, regards the Microsoft statement above. Every so often, some dude/dudette comes along and wants to make everyone do something _their_ way. So I see tremendous potential for good with this idea, but I also see a lot of possibility for creating unnecessary constraints. Its possible to define a horrible standard.
So, y'all are definitely my peers. What do you think? Shall I just keep it MP3::UNC and see what kind of reception it receives (which I fear will not be enough exposure for the potentially cool idea), or propose a UNC parent?
Man, do I love it when my laziness breeds generosity in my code. Cooooooool.
brother dep.
--
Laziness, Impatience, Hubris, and Generosity.
2001-04-21 Edit by Corion : Moved to Meditations