[HN Gopher] What ID3v2 could have been
___________________________________________________________________
What ID3v2 could have been
Author : lawik
Score : 72 points
Date : 2022-06-07 19:01 UTC (3 hours ago)
(HTM) web link (underjord.io)
(TXT) w3m dump (underjord.io)
| johnmaguire wrote:
| I really wish there was a standard for storing music metadata
| alongside the media itself (i.e. in a separate file.)
| jandrese wrote:
| 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.
| iggldiggl wrote:
| > 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.
| lawik wrote:
| 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 :)
| dev_snd wrote:
| 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.
| AdmiralAsshat wrote:
| 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.
| deadbunny wrote:
| Check out Musicbrainz Picard[1]. If the releases have their own
| entries in the Musicbrainz database (which they very likely do)
| you can differentiate between releases in both tagging and
| directory structure.
|
| I've not personally done this as I only keep one copy of each
| album (whichever I think is the best, subjective I know but
| it's my collection) but they have a powerful file naming
| scripting interface[2] which you can probably come up with
| something to satisfy your needs.
|
| Obligatory: Make sure you perfect this with your edgecases on
| some copies of the files first!
|
| 1. https://picard.musicbrainz.org/
|
| 2. https://picard-
| docs.musicbrainz.org/en/config/options_filere...
| aaaaaaaaaaab wrote:
| - TDOR: original date
|
| - TDRL: release date
|
| 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 wrote:
| Thanks! I'm highly suspicious that any of my mp3 players or
| player software can actually sort by these fields, though.
| iggldiggl wrote:
| 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).
| 1970-01-01 wrote:
| >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.
| rasz wrote:
| Updating 32-bits long rewrites 2-5MB on a flash memory devices,
| genius specification!
| layer8 wrote:
| Doesn't flash memory support rewriting single blocks?
| philjohn wrote:
| Especially on an SSD
| LanternLight83 wrote:
| 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.
| mongol wrote:
| 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.
| throwaway92394 wrote:
| But more importantly - can we embed ID3v2 inside ID3v2?
| blep_ wrote:
| You can encode the inner one into a QR code and use that as
| album art. The rest is just optimization.
| lawik wrote:
| I haven't tried but that should work fine unless the specific
| parser gets up to some shenanigans.
| tootie wrote:
| 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 wrote:
| 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.
| layer8 wrote:
| > 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.
| jrm4 wrote:
| 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.
| MBCook wrote:
| 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.
| degenerate wrote:
| I imagine the author has never seeded a torrent or managed
| backups ( _edit: author replies_ )
| lawik wrote:
| 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.
| ballenf wrote:
| I loved the whimsy. Felt a little like the exact opposite
| of a black mirror episode. Or maybe a world where
| jrm4 wrote:
| You know, I think in the back of my head I probably thought
| that, but it still just gave me the heebie-jeebies.
| throwawaymaths wrote:
| 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.
| marcodiego wrote:
| 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.
| bayindirh wrote:
| 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.
| bmacho wrote:
| 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.
| bayindirh wrote:
| 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 wrote:
| 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 wrote:
| > 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
|
| 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
| jandrese wrote:
| 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.
___________________________________________________________________
(page generated 2022-06-07 23:00 UTC)