Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: New container format for all album media? (Read 4417 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

New container format for all album media?

I have an idea for creating a standardized container format for the distribution and playback of multimedia.  One of the problems with typical "container" formats is that they seem to reinvent the wheel to some extent by creating new codecs or otherwise imposing upon the user.  My idea is pretty basic and involves using formats and standards that already exist. 

I thought of this while trying to come up with a better way to distribute my latest EP of music, Love & Affection, in lossless formats (shameless plug.)  I had compiled together a .zip file with a single FLAC file, stand alone cue sheet, and PNG files of the artwork.  One of my concerns was that when an uninitiated user downloads this file, they may not know what to do with it.  Most computer users are at least familiar enough with zip files to extract the contents.  But, then again, we're left with a potentially confusing array of files in many formats.  It's a far cry from the closed but slick iTunes model.

What if we did the exact same thing that I did, more or less, but included an XML file in the zip archive that described, in some standardized way, what each file was and the function it plays in the context of the overall media product.  Then, with this information, we could parse the data inside the zip file for playback as a whole media package. 

Take Dan_Connor_-_Love_and_Affection.mm.zip for example:

  love_and_affection.xml
  love_and_affection.flac (or .mp3)
  love_and_affection.cue
  love_and_affection_lyrics1.txt
  love_and_affection_lyrics2.txt
  love_and_affection_lyrics3.txt
  love_and_affection_cover.png (or .jpg)
  love_and_affection_sleeve1.png
  love_and_affection_sleeve2.png
  love_and_affection_sleeve3.png
  ...etc.

love_and_affection.xml:

<media>
  <type>musical album</type>
  <title>Love & Affection</title>
  <artist>Dan Connor</artist>
  <year>2008</year>
  <front_cover>love_and_affection_cover.png</front_cover>
  ...
  ...
  <song>
    <name>Exactly as it Seems</name>
    <track_no>1</track_no>
    <audio>love_and_affection.flac</audio>
    <graphic>love_and_affection_sleeve1.png</graphic>
    <lyrics>love_and_affection_lyrics1.txt</lyrics>
  </song>
  ...
  ...
</media>

Imagine someone downloads Dan_Connor_-_Love_and_Affection.mm.zip and drags it into their music player of choice, which supports this new standard.  The music player looks inside the zip file for the XML file.  The XML file tells the player that the FLAC file is the audio and contains trackinfo, while the cue sheet can be used for burning the image.  The user can click on the track and see the lyrics for that song, as the XML file defines which song which lyrics in lyrics.txt are for.  The album artwork is similarly seamlessly digested and presented to the user without the user having to know what file inside the archive is being used. 

The archive container would allow the user to associate an 'album' with just one thing and would help bridge the gap between how a physical CD is a complete media package and how media files are just bits and pieces of the overall intended presentation. 

Now, in the event that one of these media types is not implemented in the player, such as foobar2000 not supporting album art, the player can simply ignore the extra data. 

If the user's software player or hardware player does not support the container organization, the archive still registers as a zip file with any extraction software and the underlying media can be singled out for loading in the device/player as we currently do.  It would be similar to how a tar.gz file CAN be extracted with gzip to get at the tar file, but software in-the-know does both steps transparently and presents the user only with the contents of the tar file.

This would also be useful, abeit a little more complex, for distributing digital versions of DVDs.  Or just about any combination of media types.

I would like to propose the creation of an open-source standard for such a container, focusing initially on music, and its implementation in playback.  If this means that gzip should be used instead of zip for license purposes, so be it, but I think a lot of the advantage would be in the ubiquitous nature of the zip format.  Maybe zip decompression is too much of a pain to do in realtime... so maybe use tar considering it's already largely compressed data.  I dunno.

What do you guys think?  Anyone up for coding a prototype plugin for something?

New container format for all album media?

Reply #1 –
While this seems viable, is it really practical? If memory serves me correctly, cannot all this be achieved by tags? Take FLAC for example. It supports metadata, multiple album art (with a describer for each, like cover, back, etc.), lyrics and cue support.

The same with WavPack. (I don't know if it supports album art since I keep my album art outside the files.) Though it does support metadata, lyrics, cue, etc.

So, the same with a .ZIP, can be replicated with a normal music file, even MP3. Then, if you keep the .ZIP extension (which you seem to want to, instead of introducing yet ANOTHER extension that can confuse the user), what if they unzip it? Now they have all these miscellaneous files, and no reason or purpose to have them.

Maybe I am looking at this at a different point of view, but do you think it's really necessary?
 

New container format for all album media?

Reply #2 –
I wasn't aware that the FLAC metadata had all those options... that would certainly be awesome if it were well supported.  I only knew it supported cue sheets.  I guess that serves the purpose of what I was proposing.  I just wasn't aware of a way to wrap it all together in a way that's transparent to the user.  As far as you know, are there any software implementations of FLAC in a music player that presents the user with all that metadata?  Is all of this part of the original FLAC spec?

As far as my idea goes, I would think that the unzipping capability would be a benefit.  That way one could get at all the components of the album, if necessary, right in the file system instead of loading up a program to sort out the data from the container.

Quote from: cubanresourceful on
While this seems viable, is it really practical? If memory serves me correctly, cannot all this be achieved by tags? Take FLAC for example. It supports metadata, multiple album art (with a describer for each, like cover, back, etc.), lyrics and cue support.

The same with WavPack. (I don't know if it supports album art since I keep my album art outside the files.) Though it does support metadata, lyrics, cue, etc.

So, the same with a .ZIP, can be replicated with a normal music file, even MP3. Then, if you keep the .ZIP extension (which you seem to want to, instead of introducing yet ANOTHER extension that can confuse the user), what if they unzip it? Now they have all these miscellaneous files, and no reason or purpose to have them.

Maybe I am looking at this at a different point of view, but do you think it's really necessary?