On defining conventions and unification...

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.
[download]

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

Comment on On defining conventions and unification... Select or Download Code

Replies are listed 'Best First'.
Re: On defining conventions and unification... by footpad (Abbot) on Apr 21, 2001 at 21:17 UTC
Interesting idea; it could work...if you can get a number of people to follow your conventions Just a few thoughts from a dinosaur: In discussions regarding programming standards, naming comventions can be among the most flame-inducing topics (along with formatting and white-space issues). Put simply, people usually have a certain set of preferences and don't like changing them unless there's a really good reason. For example, I'm an old DOS hack and it bugs me to have too many files in a single directory. So, while I've organized my MP3's using a similar convention, I've done it using directories, e.g: `Ween/Chocolate and Cheese/01 - Take Me Away.mp3`. Mind you, I'm not saying that it's a better convention than yours; it's mine and it works for me. What I am saying that instead of dictating the naming standard, why not a) provide a default behavior (your's) and b) provide an interface for overriding that behavior. For example, File::Find calls a user supplied subroutine for dealing with files matching the search. Using the same idea, you can allow people that don't like your convention to tailor your module to their own preferences. Um, certain versions of Windows use case-sensitive file systems. And, since OS X is based on Unix (to some degree), I'm guessing that certain Mac's may use (or support) case sensitive file names. The point being that things change and it's dangerous to make blanket statements. You might think about how your UNC handles a) organization by genre, b) organization by other elements in the file name, e.g. alphabetically by album Title. Track Number is only relevant to the original album that the cut was ripped on. If the user is burning their own music CD's, that may or may not be a problem. Why not strip the track number out of the filename and create a separate track index as a text file? Or--again--provide a way for the user to do the same? What standards already exist? If none, what conventions are Real and M$ using with their players? Have you searched for other thoughts on the subject? There may already be discussions and/or prior work you can take advantage of. Just ideas to ponder is all... --f	[reply] [d/l]
Re: Re: On defining conventions and unification... by deprecated (Priest) on Apr 21, 2001 at 23:35 UTC
I guess a code sample would have really cleared up what I wanted to do. However, I think it would be very easy, given the hashful nature of perl to do something like this: `use UNC::MP3::FootpadConvert qw{ convertfromfootpad }; my $cfilename = convertfromfootpad( $file );` [download] update: I forgot to address track numbers. Well, track numbers, yes, are only important if youre writing or reading tracks from a CD. however, if you dont have the CD (lets say you are in fact violating copyright laws and downloading mp3's without discs and keeping them) -- but you want to listen to it, it would be nice to have the tracks numbered. Take for example, Floyd's Dark Side of The Moon. Throughout the entire CD there is a background track. However, if I had all the files and they were named "Money", "Total Eclipse" and so on, they would have no consistency. So while a track number isnt imperative to normal mp3 usage, it is very important as people begin to "collect" mp3's. Similar to my $MP3::UNC::dl (debug level) variable, it would be easy to hack together a $MP3::UNC::ignore_track_no. However, I also think that people who have a large collection of miscellaneous mp3's (as I do too) are not going to be spending a lot of time organizing them. dig? So that isnt so much of an issue. I'll post some code when I've got the OO stuff working happily. -- Laziness, Impatience, Hubris, and Generosity.	[reply] [d/l]