I’ve not tried every online music store nor every music file format, but far as I know, there’s no file format that replicates the experience of buying a physical record, whether that record’s on vinyl, CD, cassette, or some more esoteric format. All I mean by “replicates the experience” is that the file format should provide the songs in the highest quality the medium will allow, should include all the album artwork and liner or inlay card that would come with the purchase of the physical album, and should provide a recommended playlist order for the tracks complete with a recommended gap between each track.
It’s not a lot to ask.
I propose that online music stores should, except perhaps when they are selling solitary songs, sell their records in a format that includes all of this. It would probably be something like a JAR file but for musical records instead of Java programs. Each file would have a copy of the inlay card and cover art as a PDF or suchlike, and a playlist in XSPF or similar. The tracks would also be included in the JAR (or whatever; let’s call it a UZQ file in honour of Michael Paradinas’s best-known alias) file as FLAC files.
How hard would this be to implement? For a major online music retailer like 7digital or iTunes, not very difficult. What about player software? Most player software could very rapidly be extended to accommodate such a file structure.
So, why hasn’t this been done? Is the industry waiting for someone to write a UZQ file format specification? Has someone already written an archive file specification for music based on JAR, TAR, XAR or similar, but it didn’t catch on? Please leave your thoughts and insights as comments below. Thanks!
Yes – there should be opportunities for all sorts of visualisations. We are supposed to be in a multi- not a compartmentalised media age, after all.
I agree that this is a good idea, in that I personally would find it useful. However, knowing how strange my preferences are in comparison with the mainstream, I don’t think there’s much demand for it outside what is the small minority of people (these days) who listen to albums. Being able to buy single tracks seems to be a big appeal of online music purchasing.
On the other hand, I shouldn’t be so pessimistic. These days online audio is no longer sold in such horribly low-bitrate encodings as it used to be, even though most people don’t care about audio quality. So perhaps there is scope for a slow “bubbling up” of these things… maybe all it takes to get off the ground is an enterprising individual who concocts a format and implements support for a few popular players? Hmm.
I’d say it needn’t mandate a particular archive format — just the directory structure and some content-type standardisation is enough. Maybe just an audio CD table-of-contents plus a html directory? My CD-ripping script already saves the TOCs, so I have a record of the inter-track gaps and any data tracks etc.
Glad you both essentially agree.
Stephen, I’m puzzled by your last paragraph. How would you go about storing a directory structure in an easily distributable form, if not in an archive file of some kind? What does HTML have to do with it? And finally, is your CD-ripping script available online?
Ta
I was just saying that you don’t need to dictate how the directory structure is encoded — that doesn’t mean you couldn’t encode it at all. But if I like tar files and you like zip files, that’s no reason for one or other of us to be violating the spec. The player and/or operating system can work out the choice of encoding quite easily. In fact I’d probably want to keep my “albums” in a completely unarchived form, just as directory trees on my hard disk — except when sending them around to people. Then an archive is more convenient, although only because our software does “send file” but not “send directory structure”. By contrast, good media player software does understand how to “play a directory”, not least because DVDs are most easily ripped into a verbatim (de-CSS’d) directory tree.
I was envisaging the artwork could be encoded as a mixture of HTML (probably just image-maps) and images. I imagine Flash would be many people’s choice though….
My CD-ripping script is not yet available, as its interface is a bit esoteric at the moment. But I’ll take that as a request to put it out there sooner rather than later! I have tons of scripts I really should put on the web.
Thanks for clarifying your point about directories. My main reason for suggesting an archive format is that this way you wouldn’t need to unpack your album downloads. After all, if media player software can play directories and if Java can “play” .jar files, why can’t media player software play archive files? Also, keeping the whole lot – music and inlays – bundled in one file is much like keeping, say, a CD and inlay in a CD case: you reduce the risk of them becoming separated. Finally, having one file per album (albeit with the ability to ask your media player to copy out individual tracks on demand) is probably more manageable for most folks than maintaining a file tree per album, especially a file tree with a range of different file types. The latter situation is pretty much the current one, and I think it encourages a lack of standardisation that reduces, rather than promotes, the likelihood of online retailers selling records (rather than just tracks) in a standard format.
In favour of your point, though, there’s some discussion on the WHATWG mailing list about making it easier to upload/download directories rather than just files.
As for having artwork stored as HTML, I think that’s also not quite ideal. Album artwork tends to be laid out very precisely, something for which HTML is a notoriously poor format (though admittedly image maps lay out more reliably than most elements), not least because of browser shortcomings. Hence my advocation of PDF.
I look forward to seeing it your CD-ripping script. If it can be written in some cross-platform way, and if it can output both FLAC and VORBIS (I like to bifurcate: a full-quality copy for archiving/reference and a lossy-compressed copy for portable players with limited space), so much the better
Well I’m not sure I buy the “risk of separation” argument, because the converse is “inconvenience of extracting part” and that’s a far more likely case. Everyone keeps files in directory structures on their computer, and “losing things” once they’re in such a structure is rare. By contrast, it’s very likely that I might want to send someone just one song from an album (or just the artwork). Of course Java can run JARs… but it can also run class files in a directory structure, so that’s more of an argument for “support many”. On the other hand I do buy the adoption argument, but purely for nontechnical (and moreover fairly short-term and circumstantial) reasons.
(Humans have tendencies towards overspecialisation as well as overgeneralisation… I’m trying to counter the former!)
I suppose PDF versus HTML+images comes down to whether the source encoding is vector or raster… and the vector case is very plausible. On the other hand, there’s no free software for rendering fancier PDFs yet, so that’s a [short-term, circumstantial] argument for HTML.
My ripping script can encode however you want — the encoder command is a parameter. It’s not very cross-platform though… it definitely requires a Unix-like environment, and getting the ISO images out pretty hard to make portable, so it’s done with Linux-only cdfs at the moment. Hmm, maybe plain old dd would work….
I take your point about the problem. However, stores that sell music online still need to settle on an archive format (JAR, ZIP, whatever) and a standard structure within those files, in order for downloaded albums to be able to be reliably unpacked by users into a directory structure that media player software can grok, non?
Most music companies send their album sleeve and inlay card designs to the printers as PDF files, in my experience; this is another strong argument for having PDF as the default format for the artwork in album bundle files/directories.
Thanks for emailing me your script
Since all my GNU/Linux boxes are down for the count right now ( 
partly to do with this not working quite as hoped), I won’t be able to try it in a hurry, but I’ve taken a look at the code. I see there’s no license embedded… did you have one in mind?
Thanks again.
I still don’t buy that they have to settle on one archive format, but never mind. (Another witness to my case: HTTP’s inclusion of an Accept-Encoding header for negotiating this sort of thing flexibly.) And grokking the archive (as opposed to its contents) should not really be the media player’s job either, in a closer-to-ideal world… but I digress.
I think the MIT license will do.
Hm, I wonder if MGMT might be interested in my bundling ideas? http://www.guardian.co.uk/music/musicblog/2010/jan/20/bands-dont-miss-single-thing