A very quickly-hacked (and therefore lame) CFX tag to provide info about MP3 files.
This is by no means a production quality tag. Far from it. It may work on your system, but it may also melt your server. You assume full responsibility for anything this tag does if you try to use it. I'm telling you right now: Do not use this tag.
Just like any other CFX: register the tag in the CF Administrator.
It's meant to be something akin to an extension of CFDIRECTORY's LIST action. It therefore takes 2 attributes, NAME and DIRECTORY. The value of the NAME attribute becomes the name of the returned query. The value of the DIRECTORY attribute is the directory you want listed. Duh.
The returned query has the following columns:
Column | Value |
---|---|
Name | The filename. |
Size | The size of the file. |
Type | Possible values: MP3, Dir |
Mode | Empty. |
Attributes | Empty. |
DateLastModified | The date the file was last modified. |
Artist | Artist from the ID3 tag. |
Album | Album from the ID3 tag. |
Track | Track number from the ID3 tag. |
Title | Title from the ID3 tag. |
Comment | Comment from the ID3 tag. |
Genre | Genre from the ID3 tag. |
Year | Year from the ID3 tag. |
TagSize | Size of the ID3 tag. |
Not very well.
Might set a MP3DirError variable for one specific type of error, but don't rely on it.
In May of 2001 I installed a Beta copy of CF5 on a Linux dev server to see how it all worked. The dev server also happened to be our MP3 server, and was already running Icecast, so I figured I'd slap a web interface on it to make it a bit more user-friendly. I checked out the Tag Gallery and there were a few tags there that would sort-of do what I wanted, but none were readily available for Linux. Seeing a challenge, as I'd not done any Linux CFX development, I decided to write my own. What a mistake that was.
It turns out that Linux CFX development is extremely broken. You can only compile CFX tags on Red Hat 6.2 boxes, no matter what version of Linux you are running on your production server. Anything else and you run the risk of binary incompatibilities and segfaults, core dumps, etc. I rebuilt another box to RH6.2 only to find out that id3lib, the MP3 ID3 tag parser I'd chosen, only compiles on RH7 or better. Grrrr. That is why the throw() calls are all commented out in the source: it's the exception handling that introduces the binary incompatibilities. I could get it to compile, but only if I didn't use exception handling.
This is, admittedly, some of the messiest code I've ever written, and for that I apologize. I was not a happy camper at the time, primarily due to the aforementioned reasons.
PostFix: Porting it back to Win32 was interesting. I now have a new respect for people who do *nix/Win32 ports all day long. The subtleties and incompatibilities will drive you nuts. Things as conceptually simple as directory listings become astoundingly tricky.
Rick Osborne, <cfx at rixsoft dot com>