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.
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!
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).
This is the crux of it. All software chooses what elements of the "spec" it supports. There are ways to do what you want, but whether those are useful depends on your use cases and specifically the other software (and hardware) you use.
Then also some of this stuff has not been touched in years. So you can end up with quirky bugs. Like if you use picard in a particular way then give it over to windows media player, WMP sometimes will corrupt the file. However, if you tag it in the particular way it likes then it is OK. All of those fields are 100% left up to the interpretation of the program.
Then you have fun things like should you use "; " or " / " or ";" or "/" to do multi item fields. Or should the tagger put the same tag in more than once? What happens if the band/artist has that char in its name? What will the player do? Do you want utf-8 or 16? It is a quirky mess. Then lord help you if you mix in 2 or 3 different programs that have their own interpretations of all of that.
Oh then you can have all flavors of an id3 tag in one file, plus ape, etc. That may or may not be synced between each other.
Then there is the generic TXXX tag. Oh boy that thing is an interesting one. Random things are stored in them. Is it necessary? Some is, some isnt. I have seen anything from picard NVP bits, random binary data, XML purchasing data, volume leveling, etc. Then if your editor of choice does not recognize the particular NVP they usually just ignore it. So removing them is interesting.
Oh then the data in the tags themselves can be fun. Depending on your source data. You can end up with "Random Person" "Random Q. Person" "R. Person" "R. 'coolnick' Person" "Random P." and so on. Musicbrainz uuid tag for that sort of fixes it. But only if the player supports it.
There is a tool out there that does a sanity check of some of this. Unfortunately the name eludes me at the moment. I usually use it to remove extra padding. Some of the editors like to leave 2-4k extra padding in each file for if you make another update. It speeds up updating. But once you are done...
This drove me crazy enough to give up on managing a music library. I had about 45k songs and was pretty meticulous on organization at a folder level. In Winamp the dashes for filenames were slightly different from dashes from ID3 tags, and this was unacceptable, so I decided I wanted to fix all the terrible or missing ID3 tags. Manually looking up every song/album to find the release date took forever. A lot of the original tags were for the remastered year, so I'd manually look up the release date to "correct" it. If I wanted to make a smart playlist of "00s Music" I didn't want an album from the 70s showing up (or vice versa). This was often easier said that done in some cases, as release years weren't always clear, especially for albums that came out near the end of the year.
I tried one of those software packages to fix tags and that was an unmitigated disaster. I kept the blast radius small, but it trashed everything I put through it, so I gave up on using anything automatic.
I think I only made it through the Bs or Cs (going alphabetically by artist) when it came to the level of detail to get release dates.
As you mention, steaming platforms have the same issue, which I find annoying, but at least I don't feel like it's my responsibility to fix it anymore.
Oof. I recently embarked on a similar retagging project, but since I'm not that big a music listener and only had a few thousand files, I actually made it through.
On the other hand in a similar vein I decided that I wanted to geotag all my old pictures and I've got no idea whether I'll ever make it through that project, or not…
>I decided that I wanted to geotag all my old pictures and I've got no idea whether I'll ever make it through that project, or not…
This is something I should probably do as well. Lucky for me I've had an iPhone since 2007, so a good number of my stuff is geotagged, but I do have older photos and gaps due to photos given to me by others.
I just made a Smart Album in Photos to show me all the photos that aren't geotagged... Just shy of 2,000. That seems like something I can chip away at while bored.
I've always labelled those notes in parenthesis in the Album field, like your final example. I do wish it had a separate field.
The biggest pain point I have with ID3 tags is how compilations are handled, particularly when that compo is a DJ mix with individual tracks. I prefer to not have these pop up in searches unless I specifically want to listen to the whole album, so I've taken to setting the genre to "Mixed / Drum & Bass", for example. (I usually queue up music by the genre tag.) I also like to separate tracks with vocals vs purely instrumental, so those guys get "/ Vocal" appended.
iMusic on iPhone handles both cases poorly. It is sad that they are letting that app essentially rot.
Musicbrainz Picard will put the release date of the remastered album in the DATE tag, and the release date of the first release in the ORIGINALDATE tag. Some players support sorting by original release date.
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.
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 :)
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
> 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.
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.
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.
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.
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.
>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.
...does that mean ye-olde OLTP SQL leads to accelerated storage aging more than other use-cases? So doing an UPDATE to set a single `int`-column in a single row is far more expensive (in terms of wear-and-tear) than we assumed?
...could a DoS attack on any SSD-based cloud database/storage provider be done simply by doing lots of small writes?
------------
If this really is true, it makes me wonder why Intel's 3D XPoint (y'know: Optane SSD) lost its steam - it's byte-addressable (and so I assume it's also byte-writeable... right?), so surely would be perfect for OLTP scenarios like this?
At the same time, I'm not aware of any actual modern RDMBS that reads and writes anything less than a 4KB page at a time, regardless of underlying storage media, simply because 4096 bytes is such a common allocation-unit everywhere you look: Linux, Windows, HDDs, SSDs, NTFS, extfs, even btrfs defaults to 4KB for file extents.
Can anyone with experience with the internals of "serious" RDBMS (i.e. MySQL, PostgreSQL, Sybase, MSSQL, Oracle, etc) explain exactly what happens at a low-level on-disk or on-SSD (or on-SAN?) when you run a SQL UPDATE to overwrite a single `int` column in a single row?
Usually the whole row is copied, updated, and then appended to a different file on disk. After some time a job runs that removes the unused rows by deleting them for good, thus rewriting files and compacting the database. This has lots of advantages, on a small scale resilience against power outages (journaling), and on a large scale you can e.g sync a second DB / backup by just streaming appends.
Simplifiying a lot here of course. E.g if your DB uses MVCC (multiversion concurrency control) old values cannot be removed until the last transaction is done seeing them.
Of course if you write your own storage engine you can do whatever you want. I wrote one for MariaDB a few years ago and you basically just have to implement the minimally required interfaces for it to work.
DBs traditionally have these technical details figured out pretty well, and the line between what is part of the DB and what is done by the OS can be blurry at times.
At least for SSDs the description I read was something like yes,you can write a single block if you only need to turn 0s into 1s, but no for the reverse, which requires erasing a whole group (forgot the precise term for that) of blocks.
In NOR flash erase actually sets all bits to 1. Afaik same thing for NAND flash, but in case of SSD its abstracted away, especially if drive implements compression.
I actually meant blocks on the file system level, meaning that you don’t have to rewrite the whole MP3 file once the play count field is there. Of course that might still mean that more has to be rewritten on the flash storage level, but that would be independent from the MP3 file size.
Modifying files in place seems to be very rare outside of OS. Do you know of any every day programs doing it other than actual disk editors? Not even Hex Editors get it right.
HxD will modify file in place one character at a time, that is individual WriteFile commands per byte. Depending on write caching policy modifying 100KB of a file has a chance of generating 100K*(cluster size) total written bytes to SSD.
Frhed DGAF and replaces whole file in place from offset 0 no matter the size of a file, offset of edit or size of edits.
The safe way nowadays is write new file, rename, delete old one. Best case scenario you get appends.
> Modifying files in place seems to be very rare outside of OS.
It’s difficult to tell how common it is, but it is trivial by either using seek() and write() or by mmap()-ing a file. I’ve done the former for the purpose of simulating virtual memory to work with multi-gigabyte data structures in 32-bit memory space. Dropbox does it when syncing changed blocks within a file. Databases usually do it.
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.
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.
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.
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.
Kind of agree, but the obvious reason for doing it this way is so that you can support using multiple different players, or different users in some cases. Ideally a separate container for metadata, agreed by all, would be used but it takes time and some sort of special magic for such de facto standards to be agreed.
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.
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.
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.
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.
I remember when they added them years ago, and they were okay, and I was happy with them. Then they removed them and changed the lyrics button to say "lyrics will be back soon". Then they removed that button.
Years later, they added back the lyrics button, but it's on so few songs if you don't listen to major artists. I understand a lot of that is on the artist's end, but the situation would be much better now if it was never removed.
I'm being pedantic, but it's one of many reasons I dislike Spotify these days, despite using it at this very moment.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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!
> 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.
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.
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.
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 ;)
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?
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…
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.
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.
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).
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.
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.
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.