10 ms·

What ID3v2 could have been

166 points by lawik 4y ago

marcodiego 4y ago
I think ID3v2 covered well its purpose. It allowed arbitrary meta-data (I think) and provided a standard for embedding even a thumbnail. I think I could have been adopted by formats other than MP3.
- bmacho 4y ago
  I too do want to add tags or other text inside my pictures, or bookmark or additional stuff inside (and outside but attached to) my pdfs. ID3v2 would be so nice.
  - jandrese 4y ago
    The idea of having a metadata resource attached in a standard way to every file is certainly tempting. Apple's Resource Fork is an example of it working well right until the point you need to copy said file over to a system that has no knowledge of it.
  - bayindirh 4y ago
    You can attach sidecar files to your images. XMP is such a standard for storing additional, arbitary (meta)data with your image file. Many photo applications are writing their own XMP files for storing additional data. Darktable uses it to store editing history, for example, to enable non-destructive editing of the images.
    - franga2000 4y ago
      Sidecar files are such a confused approach to metadata storage. If I wanted file metadata to be portable, I'd put it in the individual files, and if I wanted it to not be portable, I'd put it in a local database (like Lightoom's .lrcat). Sidecars are somewhere im between. They are easy to miss and hard to ignore. In my experience trying to get photographers to use Darktable, the xmp files are their main complaint. Luckily you can disable them now, but it's still a strange and jarring default. All that being said, I definitely appreciate the elegance of using sidecars from a software point of view. They are a decent and sometimes necessary compromise. If I was a developer given such a task, I'd probably suggest the same approach. But as a user...no thanks!
      - codetrotter 4y ago
        > In my experience trying to get photographers to use Darktable, the xmp files are their main complaint. I remember Adobe Bridge would do this as well. I only used Bridge for a short while during the Creative Suite 2 era, so I don’t know if Bridge does this still or not. Here’s an old thread from 2005 on a forum site where some people discuss the xmp files created by Bridge. https://forum.luminous-landscape.com/index.php?topic=9151 https://forum.luminous-landscape.com/index.php?topic=9151 The first version of Bridge was released earlier that same year [1], as part of Creative Suite 2, so the discussion in the above thread is about that same version of Bridge for sure. The next version of Bridge came a couple of years later, in 2007 as part of CS3. I also remember that prior to the release of Bridge 1.0 as part of CS2, there was a public beta version of Bridge that I tested, which was pretty much the same as the eventual version that was released as part of CS2. [1]: https://en.wikipedia.org/wiki/Adobe_Bridge https://en.wikipedia.org/wiki/Adobe_Bridge
  - lawik 4y ago
    ID3 is not formally tied to any file format. It can exist without a media file or with any other file. It was conceived of for MP3 files but nothing should be stopping you ;)
- bayindirh 4y ago
  ID3v2 can store multiple images inside at arbitrary sizes with additional metadata (front cover, inlay, etc. incl. user defined names). FLAC uses Vorbis tags which are very similar to ID3v2. AAC is also using its own tags which are very similar to ID3v2. The tool I use (Kid3) treats all the same.
jandrese 4y ago
This article goes off the deep end a bit on a tangent about modifying documents to track their history. That play count field in the ID3 tag was a hack and almost nobody used it. The idea was to allow the metadata to be shared between different programs, but it immediately ran into a snag when you remembered that files can be copied and there was no mechanism to synchronize the updates across all copies of the file. Automatically tagging files with information that might be personally identifiable (bought media from retailer X on date Y) is also the sort of thing that turns off users in a hurry. The possible benefits are far outweighed by the potential problems.
- lawik 4y ago
  I absolutely get that. In many ways what excited me about seeing all these frames was the sense of possibility completely untempered by practicalities. I wrote it in the spirit of taking the idea and going with it, off the deep end if you wish :)
  - gfody 4y ago
    I'm thinking of some engineer just doing his job, imagines a future where files dont exist and information is stored relationally in some sort of universal shared database, but tasked with designing a file format for everything you could possibly want to link to a piece of sound, and as a way to protest the broken design came up with outrageous tag specs to exaggerate the shortcomings of flat files, back when filesystem technology was still frontier
- iggldiggl 4y ago
  > Automatically tagging files with information that might be personally identifiable (bought media from retailer X on date Y) is also the sort of thing that turns off users in a hurry. At least the iTunes store actually does that.
- xoa 4y ago
  iTunes supports play count and always has, and I and friends have made use of it extensively (albeit for ourselves not shared) including for things like smart playlists where it's great for natural curation/discovery. Now that it's mentioned, I don't actually know if iTunes made use of the ID3v2 tag or its own database for that. Our music libraries are synced across devices and it seems to carry around fine, or at least close enough since a bit of fuzziness doesn't actually matter much in this case. A play count of 60 vs one of 61 or 62 isn't particularly meaningful since both show roughly that this is a song you have listened to quite a bit. It is useful though. In the iTunes implementation at least I think (I haven't checked in a decade or more, it was like this once but not sure about the latest) it only advances when a song is completed, not when it's started. So having a song come up one doesn't like that they immediately skip will appear in the number as the years go by.
throwaway92394 4y ago
But more importantly - can we embed ID3v2 inside ID3v2?
- lawik 4y ago
  I haven't tried but that should work fine unless the specific parser gets up to some shenanigans.
- blep_ 4y ago
  You can encode the inner one into a QR code and use that as album art. The rest is just optimization.
- pwdisswordfish0 4y ago
  Sure, every frame announces its own length in the frame header, so the frame content iself does not need to be escaped (apart from the usual escaping of MP3 synchronisation markers, called „unsynchronisation“, but that’s not relevant to the question at hand).
jrm4 4y ago
Ewww absolutely lost me at "playing an mp3 could modify the file itself." If you wanna hash the song and allow mp3 players to opt into a database or something to track plays, fine. But modifying the file? Nopenopenope.
- degenerate 4y ago
  I imagine the author has never seeded a torrent or managed backups (edit: author replies)
  - lawik 4y ago
    I did not seriously mean to make you think I thought this was an actually good idea. I find the idea delightful and amusing, not good. I've dealt with torrents, large file databases and backups. Well aware of hashing which makes this more amusing, not less, in my eyes.
    - throwawaymaths 4y ago
      If you want a fun romp down computer history, check out BeFS, which had basically databasing filesystem metadata. For mp3, it extracted all of the id2 metadata and then seeded the database; if you made a change it wouldn't affect the file payload.
    - ballenf 4y ago
      I loved the whimsy. Felt a little like the exact opposite of a black mirror episode. Or maybe a world where
    - jrm4 4y ago
      You know, I think in the back of my head I probably thought that, but it still just gave me the heebie-jeebies.
- MBCook 4y ago
  What about backups? Every time I play an MP3 my backup program should re-backup the entire multi-Meg file because a single byte changed? I like having a play account, but that does not seem like a good solution at all.
1970-01-01 4y ago
>The thing that first got to me was what really made me see the MP3 + ID3 file in a different light. Play counter (PCNT). This mighty little frame contains a number and it is intended to be the number of times the file has been played. According to spec it should be incremented when it begins playing. This means that the file changes as people “consume” the media in it. Thanks, I hate it.
- philjohn 4y ago
  Especially on an SSD
  - LanternLight83 4y ago
    I don't know that the number of times a track is started would have any perceptible impact on an SSD, especially given the small size of the write (much smaller then, eg., a game save). I do think it would be cute to have an old rip of my favorite ambient YouTube mix that has accumulated hundreds of plays, even if that count isn't synced between devices (it'd accumulate them on whichever device I actually played it off of), and that that sort of passive, local scrobbing is worth at least as much enjoyment as a small game save.
    - philjohn 4y ago
      I suppose it depends - although it's pretty much the worst case for write amplification, 1-4 bytes leading to a 4k block erase and reprogram.
      - codeflo 4y ago
        True, but if you’re just listening and not for some reason updating your whole library, we’re talking about one block write every three minutes or so. That’s negligible compared to everything else the system is doing.
- rasz 4y ago
  Updating 32-bits long rewrites 2-5MB on a flash memory devices, genius specification!
tootie 4y ago
I'm not an expert on the intricacies of ID3 but I can tell you that major drivers for updating the standard are not for people's winamp libraries. It's for professional audio distributors who need accurate download metrics and clear ad placements.
- dylan604 4y ago
  Those people are the absolute least of my concerns. I want to be able to find my music without spending 20 minutes looking for something like it was Netflix.
AdmiralAsshat 4y ago
I still run into challenges with ID3v2 tags on a regular basis trying to manage my offline music collection. One of the most frequent problems is how to organize various pressings of an album. Specifically, if I have an album that was originally released in 1970, but my copy in question is a Remaster from 2001, what do I use for the year? 1970, or 2001? You might initially think to pick the Remaster year, but let's assume that this is Album II of Famous Band, and I don't happen to have a rip of the original release. Now when I'm navigating through the band chronologically (as I usually do), the order looks like this: Famous Band - 1968 - Album I Famous Band - 1969 - Album II Famous Band - 1974 - Album IV Famous Band - 1980 - Album V Famous Band - 1990 - Album VI Famous Band - 2001 - Album III (Remastered) My solution thus far has been to tag the album with the original release year, but then change the Album Name to "Album III (Remastered, 2001)". It's still not perfect, though. It's somewhat gratifying to see that streaming platforms have the same problem, though, as I can see on Spotify/Tidal/Youtube Music that they regularly disagree on the release date of an album if their source is the remaster or re-release pressing.
- aaaaaaaaaaab 4y ago
  - TDOR: original date - TDRL: release date https://wiki.hydrogenaud.io/index.php?title=Tag_Mapping https://wiki.hydrogenaud.io/index.php?title=Tag_Mapping Unfortunately ID3 doesn't define a VERSION tag like Vorbis does, which can be used to store the "Remastered", "Japanese Version", etc. metadata.
  - AdmiralAsshat 4y ago
    Thanks! I'm highly suspicious that any of my mp3 players or player software can actually sort by these fields, though.
    - iggldiggl 4y ago
      I found that MusicBee supports it, but yeah, generally support for that tag seems to remain pretty exotic, and I've got no idea either whether any Android music players support it. Compilation albums pose similar issues, by the way. If I tag the release year of the compilation album, then the individual songs won't be filtered correctly if I want to do something like "play 60s music" or "play 70s music" etc. (and the same issue also applies to your "remastered album" scenario), and if I tag the original release years of the individual songs, then the positioning of the album will be a bit wonky (and I've found that some software uses the earliest date found for the whole album, whereas other software uses the perhaps somewhat more sensible latest date. I'm sure some software exists out there that simply uses the date of the first/last track [1], as well). Next problem is that support for timestamps more fine-grained than a year is equally spotty, so if an artist has released multiple albums in one year that don't happen to sort alphabetically, you also run into problems. To some extent you can override it by setting a custom sort order album name, but that can cause other issues elsewhere (i.e. when you do want to actually sort the albums alphabetically) and isn't supported by all players, either. Curiously enough, I've found that files bought from the iTunes store often come with a full timestamp in their tags, even though iTunes itself only supports years, i.e. you can only view and enter a year within the UI and the full timestamp doesn't even appear to be used internally behind the scenes, because multiple albums released within the same year are still only sorted alphabetically even if they have full timestamp tags with the proper dates set. [1] In fact iTunes does that for displaying the genre of an album – it just uses the genre of the first track, regardless of how representative that might be (or not).
dev_snd 4y ago
I have authored a small library for reading audio metadata in Python and I can say with certainty that ID3v2 is really one of the weirdest of all the meta data formats. For example between version 2.3 and 2.4 the size of the bytes to store information changed from 8 bit per byte to 7 bits per byte. In Version 2.4 they wanted to have the MSB always set to zero so it doesn't trip up hardware mp3 decoders in portable mp3 player that use the MSB so sync to audio dataframes. (Otherwise you may listen to the screaming loud noise made by the device turning your metadata into audio) Many parts of the spec are just being able to parse different buggy implementations of audio tagging programs from the early 2000s. It really was the wild west back then. Looking at it now is really charming as the post elaborated.
- brokenmachine 4y ago
  >ID3v2 is really one of the weirdest of all the meta data formats Obviously you've never experienced the shitshow that is HL7.
radlad 4y ago
I really wish there was a standard for storing music metadata alongside the media itself (i.e. in a separate file.)
mongol 4y ago
What really surprises me is that there seems to be no standard to geocode an audio file. A photo can contain coordinates in the EXIF tag but for audio there is no such thing as a far as I know. I have been looking for a voice recorder that could do that. I think it would be really useful for personal notes. But have come up empty.
- al_borland 4y ago
  Apple's Voice Memos uses your current location as the default name for the voice note. As far as I know it's not geotagged in the same sense that a photo is, but for personal notes it seems good enough.
- astrange 4y ago
  > A photo can contain coordinates in the EXIF tag but for audio there is no such thing as a far as I know. And yet this isn't good enough - I often wish I had the orientation or sometimes the z-coordinate but it's not saved.
- lukasb 4y ago
  for audio/video, would you want a single lat/long per file, or a continuous stream with run-length encoding?
  - mongol 4y ago
    For me, a single lat/long would be sufficient because I would only make a short voice memo in each file. But I can certainly understand that it would not be sufficient for cases with long files when you move during the recording.
layer8 4y ago
> I wonder if this was imagined to be used so that when you got a sample of a song in MP3 format it could come pre-loaded with ratings from a site or something. My first thought was shared file systems, e.g. a file server on a home network where each user would play MP3s from their client computer and could store their individual ratings in the files without overwriting any other user’s rating.
- usrusr 4y ago
  Dorm network SMB. There was a brief period of time, when mp3 were already a thing but before they were made truly ubiquitous by widespread p2p filesharing, in which every group of young people living together in ethernet range developed a habit leaving the PCs with the nicest music collections running through their nights. The idea of a play counter would have felt like a natural refinement to everyone involved. Not much different from the website visitor counter gifs that were still not entirely gone.
jjice 4y ago
I really wish that the synchronized lyrics metadata was standard, and had been for years. The lack of lyric support in file formats, as well as through streaming services will always make me upset, seems like such a big thing to leave out. Subtitles are such a common thing to find with a video file (I believe there may be a law about films and subtitles in the US, so maybe that's it), but you're pretty SOL for synchronized lyrics.
- deleted 4y ago
  [deleted]
- encryptluks2 4y ago
  The reason being and I don't agree with it is that the karaoke and sing along market is mo money . I personally don't even think they should be able to charge to upgrade from DVD to Blu-ray to a digital download.
  - bhj 4y ago
    Karaoke versions of songs are unique productions and their producers should absolutely be compensated.
    - encryptluks2 4y ago
      That isn't what I'm referring to. I'm referring to people using apps to try to remove to the vocal portions of a song, with the same production.
- sorenjan 4y ago
  Spotify has synchronized lyrics. https://support.spotify.com/us/article/lyrics/ https://support.spotify.com/us/article/lyrics/ https://youtu.be/lTHhT7glUUU?t=30 https://youtu.be/lTHhT7glUUU?t=30
  - pledg 4y ago
    Apple Music also has a huge amount of synched lyrics
funstuff007 4y ago
Practical Common Lisp has a chapter on building an ID3 parser. Like all things in this book, it's nicely done. https://gigamonkeys.com/book/practical-an-id3-parser.html https://gigamonkeys.com/book/practical-an-id3-parser.html
K0SM0S 4y ago
If you dig too deep into media metadata, and you have a thing for perfection, on the other side of the old Dublin Core¹ spec up to our days, once back from journeys into smart personal ratings, custom-made encyclopedic listening UX, editing MusicBrainz like a madman, getting to side between Hydrogen audio and (heretic) "subjectivists", and yet more obscure (anal?) DAC & post-processing settings, there will come a day when you want to embed everything, even the freaking bit-perfect player itself in the meta of each.single.file (a few hundred KB for e.g. Foobar2K, nothing against the mega or gigabytes of media files, right?) — such that any file plays as a standalone program, with the perfectly designed ad-hoc viewing interface and playback/rendering settings. Whether a book, video, audio, even website, whatever. Gimme the one-thing self-run app-less paradigm. That day, when it begins to sound like an actual, legit good idea to write thousands of times the same piece of software in your music, photo, book, or video library, all the while tweaking parameters individually for each collection (each album, season…), and you can actually justify it rationally as a future time-saver because you already spent that much time fiddling with meta-'stuff' instead of enjoying pieces of content themselves… Then maybe, just maybe, it's time to focus on your sanity, get a life, grab a spoon, and let smarter people (and more importantly bigger teams) than the army of you_alone_in_the_dark solve the problem of sorting the world's data. Or at least, for f#$%'s sake at the very least, get paid to do it. Because let's face it, it has become a job to listen to music "properly", and that's probably not good for your vascular tension. Also, the world has moved to streaming in the meantime. Deal with it. ___ 1: have funsies https://www.dublincore.org/specifications/dublin-core/dcmi-terms/ https://www.dublincore.org/specifications/dublin-core/dcmi-t... --- Disclaimer: Any resemblance with my real life is obviously fortuitous. It is also absolutely preposterous to think that this kicked off a journey that led me to learn Linux, virtualizations/containers of all kinds (like VFIO/virtio, cgroups, deep-level stuff), eventually programming… It is expressly not because I had to "translate" some bullshit ID3vX into Vorbis comments that I wrote my first Python lines way back when. And nothing in here is of any interest to any of you whatsoever. Except, find the hardest problem you can see and try to solve it. You likely won't if it's really hard, but the journey is its own reward.
tomc1985 4y ago
Funny, I was just browsing the spec and came across the POPM field. Out of all honesty that idea seems INSANE. Storing e-mail addresses? A list of them? Were they crazy?
longrod 4y ago
I think we are way past the stage of "files as an offline singular entity" thing. Most everything these days is meant to be synced, shared, collaborated on, copied, sent etc. We are in sort of a transition stage between files and "pure data" (or whatever you wanna call it). In these days of interconnectivity something like modifying metadata or storing metadata inside a file is a deprecated concept. This is a good thing but it takes away the simplicity of files. I have worked with MP3 files (built 2 audio players for Windows) and while it's fun, its very cumbersome as well. For example the metadata is not consistent across files. Not to mention how slow IO is. Furthermore it's not synced with the file. If another program changes a file, everything else stays behind. You can resync but that's slow. This is a sacrifice we made for owning the music we bought. Today you pay a couple of dollars for a Spotify subscription and get access to millions of albums. Is that a good thing? It's certainly an evolution. You don't have to copy files around anymore if you want to share a song. You can just send a link. You don't have to manage metadata, sync lyrics, deal with quality etc. anymore. That's all done for you. It's certainly convenient but it takes away the novel feeling of owning something.
- echelon 4y ago
  Metadata should have been a container format. MP3 or video files should have been left pure and untouched, with their original checksums. These media files should have then been wrapped in a standardized binary container that pointed to the inner file as well as a metadata payload. Changing metadata shouldn't change the inner file or its checksum, which would make many tasks easy: distinguishing amongst various recordings and transcodings, consolidating metadata, stripping metadata, updating album art, etc. The storing stars (ratings), tags, etc. could be easily accomplished in a portable way without sharing them to other users.
  - iggldiggl 4y ago
    I'm not quite sure in what way that would really be different from today. "Container files" aren't a native file system concept, so arbitrary software that doesn't specifically handle media files (like programs for backing up, file sycing, file sharing, …) still couldn't distinguish between changes to the metadata and changes to the actual media content. (Even something as ubiquitous as ZIP-files as a sort of unofficial generic container format is still mostly treated as an opaque blob by that kind of software.) And as for software that does specifically handle media files: What do you think things like MP4 or OGG are? Exactly, container file formats holding the raw media data. And even without a proper container format like in MP3s (the ID3 tag is just directly prepended/appended to the raw MPEG stream) it's not too difficult, and any music player already needs to be able to skip the tag data. So nobody's stopping you from writing a fingerprinting program that only looks at the audio streams within a file, and I'm sure something like that actually already exists.
sandreas 4y ago
My audio workflow is basically command line / self-hosted: - beets [1] for music tagging - m4b-tool [2] and tone [3] for audio books merging and tagging (Note: I'm the author of these) - iTunes and an iPod Nano 7g and iPod classic 2009 to listen "offline" (although audiobookshelf supports offline downloads) - self-hosted navidrome [4] + substreamer[5] for music and audiobookshelf [6] for audio books on my android / ios devices Everything with docker containers without further dependencies. I must say, that this works pretty good so far and I never missed something really bad on id3v2.3 or mp4/m4b native tags. [1]: https://beets.io/ https://beets.io/ [2]: https://github.com/sandreas/m4b-tool/ https://github.com/sandreas/m4b-tool/ [3]: https://github.com/sandreas/tone https://github.com/sandreas/tone [4]: https://github.com/navidrome/navidrome https://github.com/navidrome/navidrome [5]: https://substreamerapp.com/ https://substreamerapp.com/ [6]: https://www.audiobookshelf.org/ https://www.audiobookshelf.org/
- spamalot159 4y ago
  m4b-tool is great! Excited to see how much of an improvement tone is. I'm just setting up audiobookshelf this week and it seems promising. My hope is that they could eventually handle the m4b conversion in their app while also fixing chapter alignment with silence checking. Right now it still requires some manual work.
  - sandreas 4y ago
    Thanks... :-) tone is mainly, because m4b-tool / mp4v2 was not capable of writing `movement` and `movement-number` tags, which I use for series and series-part and intelligent playlists in iTunes. Of course coding m4b-tool in PHP was not the best idea (no multithreading), so I had to find a possibility to integrate multiple threads with workarounds. It works, but with tone and C# these are no longer limitations I have. Audiobookshelf is evolving very quickly, so maybe one day it will provide these features. There are some rough edges, though. I also considered audioserve + app [1], but I did not have the time to try it out. [1] https://github.com/izderadicka/audioserve https://github.com/izderadicka/audioserve
jacobr 4y ago
No mention of my favorite tags TSOT and TSOA (if I recall correctly). Let’s you specify the sort title, for example “Cure, The” instead of “The Cure” and “Bowie, David” instead of “David Bowie”. The amount of time I spent on getting these right in my collection…
- lawik 4y ago
  As I was doing the work on implementing parsing and encoding I never spent much time looking at the T-frames as they all technically work the same :)
qwerty456127 4y ago
The whole idea of putting the metadata in the file, let alone using different metadata format for every type is evil. Ideally there should have been one standard for all files - always pass 2 separate streams: one for pure data (e.g. the audio waveform in case of an MP3 file) and one for the metadata in form of a key/value dictionary. MP3 tags specifically are a particularly weird thing. Music can rarely be attributed to one specific genre precisely, band and song names are routinely spelled different ways, same songs composed by one artist are often performed by another (or worse: same artist, same performer, but audibly different way another day) and everything is almost always messed up.
- anticristi 4y ago
  This is a great opportunity that humanity has lost. Imagine all the stuff that we could have done with some kind of universal metadata format, understood both by applications and OSes: - You could have indexed all files on your computer or phone, searched for weird stuff like: "Voice recordings I had in the park (GPS coordinates + radius) last year." - No odd "MIME auto-detect / file detection algorithms". - No odd "encoding detection" algorithms. - No Byte order mark (BOM). - No odd "http-equiv" for storing encoding and file type. We might have even gone as far as to implement some kind of "metadata firewall" in Internet browsers, to make sure you don't reveal more about your privacy then you choose.
  - elpescado 4y ago
    https://en.wikipedia.org/wiki/Resource_Description_Framework https://en.wikipedia.org/wiki/Resource_Description_Framework ?
    - anticristi 4y ago
      Yeah, but no. Having a graph for metadata feels overkill. I'd rather opt for key-values, like ID3 or EXIF. The French expression "usine à gaz" comes to my mind: https://en.m.wiktionary.org/wiki/usine_%C3%A0_gaz https://en.m.wiktionary.org/wiki/usine_%C3%A0_gaz
wheels 4y ago
I wrote the most widely used implementation of ID3v2 (TagLib), and honestly, it doesn't even both implementing most of the really absurd parts of the spec, and nobody's ever asked for them. There are some things that I did implement (mainly at the generic frame parsing level) that have never been tested because I wrote them before unit testing was common (~20 years ago), and I've never seen a file that actually uses them. The ID3v2 spec is actually a complete disaster, horribly misjudging what was needed. Xiph (Vorbis) was a lot saner, but they didn't account well for people wanting to store binary data in tags (cover art, mostly). An almost perfect system would simply have been a property system with key / mime-type / value; mime-type could even have been restricted to 8-ish values (a byte) for simplicity.
- cies 4y ago
  I used some Ruby wrapper over taglib (and others for other formats) to dump my Mixxx comments/ratings/bpms/cuepoints(!) from Mixxx' sqlite db into the tags of the files. I did not want to reclassify/reanalyze/add-cue-points to my track lib EVER again. So far so good, it worked :) Thanks for taglib btw.
Mobes 4y ago
I thought a system like m-TAGS would be a nice way forward, as to seperate the audio file and ID3 tag into two files. http://www.m-tags.org/ http://www.m-tags.org/ It'd mean that the tagging standard could change but the audio file would remain the same as long as you don't modify it for whatever reason.

166 points by lawik 4y ago

I think ID3v2 covered well its purpose. It allowed arbitrary meta-data (I think) and provided a standard for embedding even a thumbnail. I think I could have been adopted by formats other than MP3.

bmacho 4y ago
I too do want to add tags or other text inside my pictures, or bookmark or additional stuff inside (and outside but attached to) my pdfs. ID3v2 would be so nice.
- jandrese 4y ago
  The idea of having a metadata resource attached in a standard way to every file is certainly tempting. Apple's Resource Fork is an example of it working well right until the point you need to copy said file over to a system that has no knowledge of it.
- bayindirh 4y ago
  You can attach sidecar files to your images. XMP is such a standard for storing additional, arbitary (meta)data with your image file. Many photo applications are writing their own XMP files for storing additional data. Darktable uses it to store editing history, for example, to enable non-destructive editing of the images.
  - franga2000 4y ago
    Sidecar files are such a confused approach to metadata storage. If I wanted file metadata to be portable, I'd put it in the individual files, and if I wanted it to not be portable, I'd put it in a local database (like Lightoom's .lrcat). Sidecars are somewhere im between. They are easy to miss and hard to ignore. In my experience trying to get photographers to use Darktable, the xmp files are their main complaint. Luckily you can disable them now, but it's still a strange and jarring default. All that being said, I definitely appreciate the elegance of using sidecars from a software point of view. They are a decent and sometimes necessary compromise. If I was a developer given such a task, I'd probably suggest the same approach. But as a user...no thanks!
    - codetrotter 4y ago
      > In my experience trying to get photographers to use Darktable, the xmp files are their main complaint. I remember Adobe Bridge would do this as well. I only used Bridge for a short while during the Creative Suite 2 era, so I don’t know if Bridge does this still or not. Here’s an old thread from 2005 on a forum site where some people discuss the xmp files created by Bridge. https://forum.luminous-landscape.com/index.php?topic=9151 https://forum.luminous-landscape.com/index.php?topic=9151 The first version of Bridge was released earlier that same year [1], as part of Creative Suite 2, so the discussion in the above thread is about that same version of Bridge for sure. The next version of Bridge came a couple of years later, in 2007 as part of CS3. I also remember that prior to the release of Bridge 1.0 as part of CS2, there was a public beta version of Bridge that I tested, which was pretty much the same as the eventual version that was released as part of CS2. [1]: https://en.wikipedia.org/wiki/Adobe_Bridge https://en.wikipedia.org/wiki/Adobe_Bridge
- lawik 4y ago
  ID3 is not formally tied to any file format. It can exist without a media file or with any other file. It was conceived of for MP3 files but nothing should be stopping you ;)
bayindirh 4y ago
ID3v2 can store multiple images inside at arbitrary sizes with additional metadata (front cover, inlay, etc. incl. user defined names). FLAC uses Vorbis tags which are very similar to ID3v2. AAC is also using its own tags which are very similar to ID3v2. The tool I use (Kid3) treats all the same.

jandrese 4y ago

This article goes off the deep end a bit on a tangent about modifying documents to track their history. That play count field in the ID3 tag was a hack and almost nobody used it. The idea was to allow the metadata to be shared between different programs, but it immediately ran into a snag when you remembered that files can be copied and there was no mechanism to synchronize the updates across all copies of the file. Automatically tagging files with information that might be personally identifiable (bought media from retailer X on date Y) is also the sort of thing that turns off users in a hurry. The possible benefits are far outweighed by the potential problems.

lawik 4y ago
I absolutely get that. In many ways what excited me about seeing all these frames was the sense of possibility completely untempered by practicalities. I wrote it in the spirit of taking the idea and going with it, off the deep end if you wish :)
- gfody 4y ago
  I'm thinking of some engineer just doing his job, imagines a future where files dont exist and information is stored relationally in some sort of universal shared database, but tasked with designing a file format for everything you could possibly want to link to a piece of sound, and as a way to protest the broken design came up with outrageous tag specs to exaggerate the shortcomings of flat files, back when filesystem technology was still frontier
iggldiggl 4y ago
> Automatically tagging files with information that might be personally identifiable (bought media from retailer X on date Y) is also the sort of thing that turns off users in a hurry. At least the iTunes store actually does that.
xoa 4y ago
iTunes supports play count and always has, and I and friends have made use of it extensively (albeit for ourselves not shared) including for things like smart playlists where it's great for natural curation/discovery. Now that it's mentioned, I don't actually know if iTunes made use of the ID3v2 tag or its own database for that. Our music libraries are synced across devices and it seems to carry around fine, or at least close enough since a bit of fuzziness doesn't actually matter much in this case. A play count of 60 vs one of 61 or 62 isn't particularly meaningful since both show roughly that this is a song you have listened to quite a bit. It is useful though. In the iTunes implementation at least I think (I haven't checked in a decade or more, it was like this once but not sure about the latest) it only advances when a song is completed, not when it's started. So having a song come up one doesn't like that they immediately skip will appear in the number as the years go by.

throwaway92394 4y ago

But more importantly - can we embed ID3v2 inside ID3v2?

lawik 4y ago
I haven't tried but that should work fine unless the specific parser gets up to some shenanigans.
blep_ 4y ago
You can encode the inner one into a QR code and use that as album art. The rest is just optimization.
pwdisswordfish0 4y ago
Sure, every frame announces its own length in the frame header, so the frame content iself does not need to be escaped (apart from the usual escaping of MP3 synchronisation markers, called „unsynchronisation“, but that’s not relevant to the question at hand).

jrm4 4y ago

Ewww absolutely lost me at "playing an mp3 could modify the file itself." If you wanna hash the song and allow mp3 players to opt into a database or something to track plays, fine. But modifying the file? Nopenopenope.

degenerate 4y ago
I imagine the author has never seeded a torrent or managed backups (edit: author replies)
- lawik 4y ago
  I did not seriously mean to make you think I thought this was an actually good idea. I find the idea delightful and amusing, not good. I've dealt with torrents, large file databases and backups. Well aware of hashing which makes this more amusing, not less, in my eyes.
  - throwawaymaths 4y ago
    If you want a fun romp down computer history, check out BeFS, which had basically databasing filesystem metadata. For mp3, it extracted all of the id2 metadata and then seeded the database; if you made a change it wouldn't affect the file payload.
  - ballenf 4y ago
    I loved the whimsy. Felt a little like the exact opposite of a black mirror episode. Or maybe a world where
  - jrm4 4y ago
    You know, I think in the back of my head I probably thought that, but it still just gave me the heebie-jeebies.
MBCook 4y ago
What about backups? Every time I play an MP3 my backup program should re-backup the entire multi-Meg file because a single byte changed? I like having a play account, but that does not seem like a good solution at all.

1970-01-01 4y ago

>The thing that first got to me was what really made me see the MP3 + ID3 file in a different light. Play counter (PCNT). This mighty little frame contains a number and it is intended to be the number of times the file has been played. According to spec it should be incremented when it begins playing. This means that the file changes as people “consume” the media in it. Thanks, I hate it.

philjohn 4y ago
Especially on an SSD
- LanternLight83 4y ago
  I don't know that the number of times a track is started would have any perceptible impact on an SSD, especially given the small size of the write (much smaller then, eg., a game save). I do think it would be cute to have an old rip of my favorite ambient YouTube mix that has accumulated hundreds of plays, even if that count isn't synced between devices (it'd accumulate them on whichever device I actually played it off of), and that that sort of passive, local scrobbing is worth at least as much enjoyment as a small game save.
  - philjohn 4y ago
    I suppose it depends - although it's pretty much the worst case for write amplification, 1-4 bytes leading to a 4k block erase and reprogram.
    - codeflo 4y ago
      True, but if you’re just listening and not for some reason updating your whole library, we’re talking about one block write every three minutes or so. That’s negligible compared to everything else the system is doing.
rasz 4y ago
Updating 32-bits long rewrites 2-5MB on a flash memory devices, genius specification!

tootie 4y ago

I'm not an expert on the intricacies of ID3 but I can tell you that major drivers for updating the standard are not for people's winamp libraries. It's for professional audio distributors who need accurate download metrics and clear ad placements.

dylan604 4y ago
Those people are the absolute least of my concerns. I want to be able to find my music without spending 20 minutes looking for something like it was Netflix.

AdmiralAsshat 4y ago

I still run into challenges with ID3v2 tags on a regular basis trying to manage my offline music collection. One of the most frequent problems is how to organize various pressings of an album. Specifically, if I have an album that was originally released in 1970, but my copy in question is a Remaster from 2001, what do I use for the year? 1970, or 2001? You might initially think to pick the Remaster year, but let's assume that this is Album II of Famous Band, and I don't happen to have a rip of the original release. Now when I'm navigating through the band chronologically (as I usually do), the order looks like this: Famous Band - 1968 - Album I Famous Band - 1969 - Album II Famous Band - 1974 - Album IV Famous Band - 1980 - Album V Famous Band - 1990 - Album VI Famous Band - 2001 - Album III (Remastered) My solution thus far has been to tag the album with the original release year, but then change the Album Name to "Album III (Remastered, 2001)". It's still not perfect, though. It's somewhat gratifying to see that streaming platforms have the same problem, though, as I can see on Spotify/Tidal/Youtube Music that they regularly disagree on the release date of an album if their source is the remaster or re-release pressing.

aaaaaaaaaaab 4y ago
- TDOR: original date - TDRL: release date https://wiki.hydrogenaud.io/index.php?title=Tag_Mapping https://wiki.hydrogenaud.io/index.php?title=Tag_Mapping Unfortunately ID3 doesn't define a VERSION tag like Vorbis does, which can be used to store the "Remastered", "Japanese Version", etc. metadata.
- AdmiralAsshat 4y ago
  Thanks! I'm highly suspicious that any of my mp3 players or player software can actually sort by these fields, though.
  - iggldiggl 4y ago
    I found that MusicBee supports it, but yeah, generally support for that tag seems to remain pretty exotic, and I've got no idea either whether any Android music players support it. Compilation albums pose similar issues, by the way. If I tag the release year of the compilation album, then the individual songs won't be filtered correctly if I want to do something like "play 60s music" or "play 70s music" etc. (and the same issue also applies to your "remastered album" scenario), and if I tag the original release years of the individual songs, then the positioning of the album will be a bit wonky (and I've found that some software uses the earliest date found for the whole album, whereas other software uses the perhaps somewhat more sensible latest date. I'm sure some software exists out there that simply uses the date of the first/last track [1], as well). Next problem is that support for timestamps more fine-grained than a year is equally spotty, so if an artist has released multiple albums in one year that don't happen to sort alphabetically, you also run into problems. To some extent you can override it by setting a custom sort order album name, but that can cause other issues elsewhere (i.e. when you do want to actually sort the albums alphabetically) and isn't supported by all players, either. Curiously enough, I've found that files bought from the iTunes store often come with a full timestamp in their tags, even though iTunes itself only supports years, i.e. you can only view and enter a year within the UI and the full timestamp doesn't even appear to be used internally behind the scenes, because multiple albums released within the same year are still only sorted alphabetically even if they have full timestamp tags with the proper dates set. [1] In fact iTunes does that for displaying the genre of an album – it just uses the genre of the first track, regardless of how representative that might be (or not).

dev_snd 4y ago

I have authored a small library for reading audio metadata in Python and I can say with certainty that ID3v2 is really one of the weirdest of all the meta data formats. For example between version 2.3 and 2.4 the size of the bytes to store information changed from 8 bit per byte to 7 bits per byte. In Version 2.4 they wanted to have the MSB always set to zero so it doesn't trip up hardware mp3 decoders in portable mp3 player that use the MSB so sync to audio dataframes. (Otherwise you may listen to the screaming loud noise made by the device turning your metadata into audio) Many parts of the spec are just being able to parse different buggy implementations of audio tagging programs from the early 2000s. It really was the wild west back then. Looking at it now is really charming as the post elaborated.

brokenmachine 4y ago
>ID3v2 is really one of the weirdest of all the meta data formats Obviously you've never experienced the shitshow that is HL7.

radlad 4y ago

I really wish there was a standard for storing music metadata alongside the media itself (i.e. in a separate file.)

mongol 4y ago

What really surprises me is that there seems to be no standard to geocode an audio file. A photo can contain coordinates in the EXIF tag but for audio there is no such thing as a far as I know. I have been looking for a voice recorder that could do that. I think it would be really useful for personal notes. But have come up empty.

al_borland 4y ago
Apple's Voice Memos uses your current location as the default name for the voice note. As far as I know it's not geotagged in the same sense that a photo is, but for personal notes it seems good enough.
astrange 4y ago
> A photo can contain coordinates in the EXIF tag but for audio there is no such thing as a far as I know. And yet this isn't good enough - I often wish I had the orientation or sometimes the z-coordinate but it's not saved.
lukasb 4y ago
for audio/video, would you want a single lat/long per file, or a continuous stream with run-length encoding?
- mongol 4y ago
  For me, a single lat/long would be sufficient because I would only make a short voice memo in each file. But I can certainly understand that it would not be sufficient for cases with long files when you move during the recording.

layer8 4y ago

> I wonder if this was imagined to be used so that when you got a sample of a song in MP3 format it could come pre-loaded with ratings from a site or something. My first thought was shared file systems, e.g. a file server on a home network where each user would play MP3s from their client computer and could store their individual ratings in the files without overwriting any other user’s rating.

usrusr 4y ago
Dorm network SMB. There was a brief period of time, when mp3 were already a thing but before they were made truly ubiquitous by widespread p2p filesharing, in which every group of young people living together in ethernet range developed a habit leaving the PCs with the nicest music collections running through their nights. The idea of a play counter would have felt like a natural refinement to everyone involved. Not much different from the website visitor counter gifs that were still not entirely gone.

jjice 4y ago

I really wish that the synchronized lyrics metadata was standard, and had been for years. The lack of lyric support in file formats, as well as through streaming services will always make me upset, seems like such a big thing to leave out. Subtitles are such a common thing to find with a video file (I believe there may be a law about films and subtitles in the US, so maybe that's it), but you're pretty SOL for synchronized lyrics.

deleted 4y ago
[deleted]
encryptluks2 4y ago
The reason being and I don't agree with it is that the karaoke and sing along market is mo money . I personally don't even think they should be able to charge to upgrade from DVD to Blu-ray to a digital download.
- bhj 4y ago
  Karaoke versions of songs are unique productions and their producers should absolutely be compensated.
  - encryptluks2 4y ago
    That isn't what I'm referring to. I'm referring to people using apps to try to remove to the vocal portions of a song, with the same production.
sorenjan 4y ago
Spotify has synchronized lyrics. https://support.spotify.com/us/article/lyrics/ https://support.spotify.com/us/article/lyrics/ https://youtu.be/lTHhT7glUUU?t=30 https://youtu.be/lTHhT7glUUU?t=30
- pledg 4y ago
  Apple Music also has a huge amount of synched lyrics

funstuff007 4y ago

Practical Common Lisp has a chapter on building an ID3 parser. Like all things in this book, it's nicely done. https://gigamonkeys.com/book/practical-an-id3-parser.html https://gigamonkeys.com/book/practical-an-id3-parser.html

K0SM0S 4y ago

If you dig too deep into media metadata, and you have a thing for perfection, on the other side of the old Dublin Core¹ spec up to our days, once back from journeys into smart personal ratings, custom-made encyclopedic listening UX, editing MusicBrainz like a madman, getting to side between Hydrogen audio and (heretic) "subjectivists", and yet more obscure (anal?) DAC & post-processing settings, there will come a day when you want to embed everything, even the freaking bit-perfect player itself in the meta of each.single.file (a few hundred KB for e.g. Foobar2K, nothing against the mega or gigabytes of media files, right?) — such that any file plays as a standalone program, with the perfectly designed ad-hoc viewing interface and playback/rendering settings. Whether a book, video, audio, even website, whatever. Gimme the one-thing self-run app-less paradigm. That day, when it begins to sound like an actual, legit good idea to write thousands of times the same piece of software in your music, photo, book, or video library, all the while tweaking parameters individually for each collection (each album, season…), and you can actually justify it rationally as a future time-saver because you already spent that much time fiddling with meta-'stuff' instead of enjoying pieces of content themselves… Then maybe, just maybe, it's time to focus on your sanity, get a life, grab a spoon, and let smarter people (and more importantly bigger teams) than the army of you_alone_in_the_dark solve the problem of sorting the world's data. Or at least, for f#$%'s sake at the very least, get paid to do it. Because let's face it, it has become a job to listen to music "properly", and that's probably not good for your vascular tension. Also, the world has moved to streaming in the meantime. Deal with it. ___ 1: have funsies https://www.dublincore.org/specifications/dublin-core/dcmi-terms/ https://www.dublincore.org/specifications/dublin-core/dcmi-t... --- Disclaimer: Any resemblance with my real life is obviously fortuitous. It is also absolutely preposterous to think that this kicked off a journey that led me to learn Linux, virtualizations/containers of all kinds (like VFIO/virtio, cgroups, deep-level stuff), eventually programming… It is expressly not because I had to "translate" some bullshit ID3vX into Vorbis comments that I wrote my first Python lines way back when. And nothing in here is of any interest to any of you whatsoever. Except, find the hardest problem you can see and try to solve it. You likely won't if it's really hard, but the journey is its own reward.

tomc1985 4y ago

Funny, I was just browsing the spec and came across the POPM field. Out of all honesty that idea seems INSANE. Storing e-mail addresses? A list of them? Were they crazy?

longrod 4y ago

I think we are way past the stage of "files as an offline singular entity" thing. Most everything these days is meant to be synced, shared, collaborated on, copied, sent etc. We are in sort of a transition stage between files and "pure data" (or whatever you wanna call it). In these days of interconnectivity something like modifying metadata or storing metadata inside a file is a deprecated concept. This is a good thing but it takes away the simplicity of files. I have worked with MP3 files (built 2 audio players for Windows) and while it's fun, its very cumbersome as well. For example the metadata is not consistent across files. Not to mention how slow IO is. Furthermore it's not synced with the file. If another program changes a file, everything else stays behind. You can resync but that's slow. This is a sacrifice we made for owning the music we bought. Today you pay a couple of dollars for a Spotify subscription and get access to millions of albums. Is that a good thing? It's certainly an evolution. You don't have to copy files around anymore if you want to share a song. You can just send a link. You don't have to manage metadata, sync lyrics, deal with quality etc. anymore. That's all done for you. It's certainly convenient but it takes away the novel feeling of owning something.

echelon 4y ago
Metadata should have been a container format. MP3 or video files should have been left pure and untouched, with their original checksums. These media files should have then been wrapped in a standardized binary container that pointed to the inner file as well as a metadata payload. Changing metadata shouldn't change the inner file or its checksum, which would make many tasks easy: distinguishing amongst various recordings and transcodings, consolidating metadata, stripping metadata, updating album art, etc. The storing stars (ratings), tags, etc. could be easily accomplished in a portable way without sharing them to other users.
- iggldiggl 4y ago
  I'm not quite sure in what way that would really be different from today. "Container files" aren't a native file system concept, so arbitrary software that doesn't specifically handle media files (like programs for backing up, file sycing, file sharing, …) still couldn't distinguish between changes to the metadata and changes to the actual media content. (Even something as ubiquitous as ZIP-files as a sort of unofficial generic container format is still mostly treated as an opaque blob by that kind of software.) And as for software that does specifically handle media files: What do you think things like MP4 or OGG are? Exactly, container file formats holding the raw media data. And even without a proper container format like in MP3s (the ID3 tag is just directly prepended/appended to the raw MPEG stream) it's not too difficult, and any music player already needs to be able to skip the tag data. So nobody's stopping you from writing a fingerprinting program that only looks at the audio streams within a file, and I'm sure something like that actually already exists.

sandreas 4y ago

My audio workflow is basically command line / self-hosted: - beets [1] for music tagging - m4b-tool [2] and tone [3] for audio books merging and tagging (Note: I'm the author of these) - iTunes and an iPod Nano 7g and iPod classic 2009 to listen "offline" (although audiobookshelf supports offline downloads) - self-hosted navidrome [4] + substreamer[5] for music and audiobookshelf [6] for audio books on my android / ios devices Everything with docker containers without further dependencies. I must say, that this works pretty good so far and I never missed something really bad on id3v2.3 or mp4/m4b native tags. [1]: https://beets.io/ https://beets.io/ [2]: https://github.com/sandreas/m4b-tool/ https://github.com/sandreas/m4b-tool/ [3]: https://github.com/sandreas/tone https://github.com/sandreas/tone [4]: https://github.com/navidrome/navidrome https://github.com/navidrome/navidrome [5]: https://substreamerapp.com/ https://substreamerapp.com/ [6]: https://www.audiobookshelf.org/ https://www.audiobookshelf.org/

spamalot159 4y ago
m4b-tool is great! Excited to see how much of an improvement tone is. I'm just setting up audiobookshelf this week and it seems promising. My hope is that they could eventually handle the m4b conversion in their app while also fixing chapter alignment with silence checking. Right now it still requires some manual work.
- sandreas 4y ago
  Thanks... :-) tone is mainly, because m4b-tool / mp4v2 was not capable of writing `movement` and `movement-number` tags, which I use for series and series-part and intelligent playlists in iTunes. Of course coding m4b-tool in PHP was not the best idea (no multithreading), so I had to find a possibility to integrate multiple threads with workarounds. It works, but with tone and C# these are no longer limitations I have. Audiobookshelf is evolving very quickly, so maybe one day it will provide these features. There are some rough edges, though. I also considered audioserve + app [1], but I did not have the time to try it out. [1] https://github.com/izderadicka/audioserve https://github.com/izderadicka/audioserve

jacobr 4y ago

No mention of my favorite tags TSOT and TSOA (if I recall correctly). Let’s you specify the sort title, for example “Cure, The” instead of “The Cure” and “Bowie, David” instead of “David Bowie”. The amount of time I spent on getting these right in my collection…

lawik 4y ago
As I was doing the work on implementing parsing and encoding I never spent much time looking at the T-frames as they all technically work the same :)

qwerty456127 4y ago

The whole idea of putting the metadata in the file, let alone using different metadata format for every type is evil. Ideally there should have been one standard for all files - always pass 2 separate streams: one for pure data (e.g. the audio waveform in case of an MP3 file) and one for the metadata in form of a key/value dictionary. MP3 tags specifically are a particularly weird thing. Music can rarely be attributed to one specific genre precisely, band and song names are routinely spelled different ways, same songs composed by one artist are often performed by another (or worse: same artist, same performer, but audibly different way another day) and everything is almost always messed up.

anticristi 4y ago
This is a great opportunity that humanity has lost. Imagine all the stuff that we could have done with some kind of universal metadata format, understood both by applications and OSes: - You could have indexed all files on your computer or phone, searched for weird stuff like: "Voice recordings I had in the park (GPS coordinates + radius) last year." - No odd "MIME auto-detect / file detection algorithms". - No odd "encoding detection" algorithms. - No Byte order mark (BOM). - No odd "http-equiv" for storing encoding and file type. We might have even gone as far as to implement some kind of "metadata firewall" in Internet browsers, to make sure you don't reveal more about your privacy then you choose.
- elpescado 4y ago
  https://en.wikipedia.org/wiki/Resource_Description_Framework https://en.wikipedia.org/wiki/Resource_Description_Framework ?
  - anticristi 4y ago
    Yeah, but no. Having a graph for metadata feels overkill. I'd rather opt for key-values, like ID3 or EXIF. The French expression "usine à gaz" comes to my mind: https://en.m.wiktionary.org/wiki/usine_%C3%A0_gaz https://en.m.wiktionary.org/wiki/usine_%C3%A0_gaz

wheels 4y ago

I wrote the most widely used implementation of ID3v2 (TagLib), and honestly, it doesn't even both implementing most of the really absurd parts of the spec, and nobody's ever asked for them. There are some things that I did implement (mainly at the generic frame parsing level) that have never been tested because I wrote them before unit testing was common (~20 years ago), and I've never seen a file that actually uses them. The ID3v2 spec is actually a complete disaster, horribly misjudging what was needed. Xiph (Vorbis) was a lot saner, but they didn't account well for people wanting to store binary data in tags (cover art, mostly). An almost perfect system would simply have been a property system with key / mime-type / value; mime-type could even have been restricted to 8-ish values (a byte) for simplicity.

cies 4y ago
I used some Ruby wrapper over taglib (and others for other formats) to dump my Mixxx comments/ratings/bpms/cuepoints(!) from Mixxx' sqlite db into the tags of the files. I did not want to reclassify/reanalyze/add-cue-points to my track lib EVER again. So far so good, it worked :) Thanks for taglib btw.

Mobes 4y ago

I thought a system like m-TAGS would be a nice way forward, as to seperate the audio file and ID3 tag into two files. http://www.m-tags.org/ http://www.m-tags.org/ It'd mean that the tagging standard could change but the audio file would remain the same as long as you don't modify it for whatever reason.