18 ms·

The 0.5 MB of nothing in all Apple Music files (2020)

407 points by mritzmann 5y ago

riidom 5y ago
Glad to hear I'm not the only one who stuffs as much music into their phone as possible :) Not an apple user, but I'd also enjoy some sudden extra 6% for sure.
- deleted 5y ago
  [deleted]
dwighttk 5y ago
Apple’s album art has been janky for me for 20 years. I’m sure it would be less noticeable if I had mostly mainstream music tastes, but after years of doing album art manually, Apple screwed it all up multiple times and I stopped caring as much about fighting around the time I gave in and started streaming more music.
- anentropic 5y ago
  Yeah it seems to randomly "forget" it
- reaperducer 5y ago
  Apple’s album art has been janky for me for 20 years My wife and I sync music from the same Apple Music library. On her iPhone, the album artwork is completely random. On my iPhone, it's always correct. No amount of wiping the phone, or even upgrading to new phones, will change this. Apple Music just hates her.
  - lukifer 5y ago
    I feel your pain: I have a large and meticulously tagged collection, and when I upgraded to a new iPhone, it seems to have hit "shuffle" on every single album art, even after I nuked it all and did a fresh sync. It's incredibly bizarre.
  - ungamedplayer 5y ago
    This is going to sound weird, but is your wifes phone set to a non US english (even something like australian/british english) language ? I found the same problem with my phone a long time ago for a non US english account. Once i had that configured differently than what my setting was on the app store it would do all kinds of stupid things with the artwork.
    - rrrrrrrrrrrryan 5y ago
      This is hilarious.
- creeble 5y ago
  Yes, one of my favorite jankinesses is that iTunes would put a timestamp in the jpeg header of the embedded artwork for every m4a file, ensuring that a hash of the artwork (for a library system that tried to minimize duplicate artwork) would always be unique. So you’d have a visually-identical but duplicate artwork file for every song on the album.
fredley 5y ago
Taken alone this might be unfortunate, but given Apple's long-standing trend of upselling storage at hugely inflated prices it's pretty damning.
- jamil7 5y ago
  For Apple Music it's probably a case of Hanlon's razor, it's been buggy and busted forever.
  - willis936 5y ago
    What if the incompetence is maliciously decided upon? Hanlon's razor works for individuals, but falls apart for larger institutions.
    - Ken_At_EM 5y ago
      I believe that you may be significantly underestimating the incompetence of most organizations.
    - jklein11 5y ago
      If all of the individuals are acting without malice, how could the institution act with malice? Isn't the institution just the collective will of the individuals? I could see it playing out like this, incompetence causes the problem, incompetence fails to identify the problem, incompetence fails to fix the problem.
      - deleted 5y ago
        [deleted]
      - willis936 5y ago
        That betrays the cooperative principle. Such an institution could not survive.
      - 8organicbits 5y ago
        > If all of the individuals are acting without malice, how could the institution act with malice? Isn't the institution just the collective will of the individuals? I think we are on an unproductive tangent, but these are quite important questions. An institution doesn't have its own free will, so I don't think I can claim it can have "intent to cause harm", but it can certainly cause harm. An institution is not just a collection of people, it is also the business processes and policies. While these are created by people within the institution, they stick around over time. As the world changes around the organization, well intentioned policy can begin to harm. Individual employees following policy and normal business practice (i.e. just doing their jobs) can behave maliciously without their own intent to do so (sorry, my hands are tied). An institution needs not only non-malicious members, it needs to constantly re-evaluate its practices. Importantly, when harmful outcomes are observed the institution must re-evaluate and adjust, otherwise the harm will continue. It's not enough for members to conduct their own behavior without malice, they must also observe outcomes and actively fight against the inertia of existing policy.
bombcar 5y ago
It would seem to me (probably naïveté) that if you have a variable part of a file the variable part should come after the fixed parts …
- seanalltogether 5y ago
  > For example, placing the metadata block at the end of the file means you must download (or read from local storage) the entire song before you can play it. To avoid this, encoders tend to place it before the much larger multimedia stream block. The metadata block refers to absolute positions inside the multimedia stream block measured as an offset from the start of the file. You can’t make changes to the metadata (e.g. change the spelling of an artist’s name) without reassembling the entire file to recalculate the offsets.
  - bombcar 5y ago
    I know local storage can seek to a location in a file without reading the whole thing (ZIP files start with a pointer to the metadata directory which is at the end of the file IIRC), so then all you need is a download system that lets you grab the first block of the file, and then ask for a later block without the middle blocks.
    - pavon 5y ago
      Back in the HDD days, loading music metadata was far from instantaneous even with the metadata in the front. Putting it at the back would have doubled the time needed for the UI to update. Now, that SSDs are more ubiquitous though it might be time to revisit that decision.
    - eropple 5y ago
      This requires multiple requests (or did before QUIC, things may be better now) and a server expecting range requests. It's much more reliable, considering the general mess of web requests, to put everything at the front. It was even more reliable in 2005 to do so.
  - JKCalhoun 5y ago
davidhyde 5y ago
Ripping from cd reserves 0.05% (about 5kb) for metadata. I can imagine some communication breakdown where someone thought they meant 5% (about 500kb) when specifying the number 0.05 with a % next to it. You see percentage mixups all the time.
- cdot2 5y ago
  In the article he describes how the 500kb was originally used for album art but when Apple started storing that separately they didn't remove the space for it in the music files
  - anentropic 5y ago
    It describes the author's conjecture that maybe it was for album art, but actual reason is unknown
    - EricE 5y ago
      Since the album art happens to fit *perfectly* into the space, it's a pretty solid conjecture.
      - etchalon 5y ago
        Album Art images are not exactly 500K. The percent mixup conjecture is just as evidence based as the Album Art conjecture.
        mlyle 5y ago
        Percent mixup doesn't make sense when it's 500k whether it's a short or long track.
  - Melatonic 5y ago
    I agree - 0.05% or whatever who cares - but at very large library sizes 500kb could start to add up. Then again I question who in the first place is keeping very large libraries of apple music files......
dpcx 5y ago
With the advent of streaming music as popular as it is (and surely Apple had to see that becoming the trend), this seems largely like a non-issue from a storage perspective. In fact, it's really only costing Apple more money in bandwidth because they still have to transmit that data - though I'd bet it compresses extremely well.
- fignews 5y ago
  Apple Music stores music locally. On my 512GB iPhone it’s the number one consumer of space
  - Cupprum 5y ago
    Depends whether you download it or just stream it.
  - EricE 5y ago
    And by default it works like cache. If you need space the music files are the first to go since they can just be re-downloaded.
- basisword 5y ago
  Unless they have unlimited data the end user is also paying directly for this, not just Apple.
londons_explore 5y ago
In 2022, we shouldn't be reserving any area of a file as 'spare space' like this. On the very rare occasion you adjust the artists name in a music file, the user expects the whole file will be rewritten. So just rewrite the whole file. Whats next? Photoshop only writing out a quarter of an image when I edit my ex out of a nice photo? MS Word only touching a few bytes of a 100 page document when I make a heading bold?
- Cupprum 5y ago
  > In 2022, we shouldn't be reserving any area of a file as 'spare space' like this. I completely understand your point, but maybe it would be a breaking change.
  - londons_explore 5y ago
    It wouldn't be. This spare space is entirely optional in the file format specification, and it's up to the tool that makes the file if it wants to include it or not.
- dotancohen 5y ago
  > In 2022, we shouldn't be reserving any area of a file as 'spare space' like this. In 2022, we should have file formats that are not naive of the underlying filesystem. I store my text notes in Git, but I also have two LibreOffice documents in there because org-mode doesn't handle their contents well. It would be nice of only 5% of the file had to be rewritten when I change a single word, rather than the current 91% of the file. A 5% hit to storage for a 91% reduction each time I update it would be a great trade off.
  - nyanpasu64 5y ago
    One option is to store files as a database like SQLite, which I assume is designed around not rewriting the whole file on every change. For example Audacity 3.x does this. However SQLite stores multiple files on disk for crash persistence, complicating matters. But then again so does Audacity 2, and Microsoft Office to an extent (file locking rather than data integrity). Microsoft Word used to only append changes to the document on save rather than rewriting the whole file, but this was disabled since if you deleted text and saved the file, it remained in the document. https://www.cnet.com/culture/microsoft-disabling-word-2003s-fast-save-feature/ https://www.cnet.com/culture/microsoft-disabling-word-2003s-...
ajsnigrutin 5y ago
How often do users change the metadata of music bought from Apple Music? When ripping stuff by hand, this is understandable.. you make a typo, want to add a year, do some locale changes to add local characters, etc... so in this case i see a possible need to waste 5 kB of space to save a couple of seconds after an edit. But with downloadad music with all the metadata (hopefully) correctly set, even 5kB is a waste of space.
- alan-hn 5y ago
  Isn't 0.5MB 500 KB? Not 5? Or are you referring to something else
  - SketchySeaBeast 5y ago
    They are saying that even a much smaller amount of memory than what they are wasting is a waste.
  - ajsnigrutin 5y ago
    From the article: > If you rip a CD with Apple Music using the Apple AAC Encoder (the default option), it will reserve approximately 5 kB of free space inside each file for this purpose. I was saying that even this is too much, and 500kB is 'way way too much'.
  - lelanthran 5y ago
    > Isn't 0.5MB 500 KB? Not 5? Or are you referring to something else The article said that the default is 5KB but Apple uses 500KB, hence the poster is saying that even 5KB is overkill.
- thought_alarm 5y ago
  I always edit the genre so that the tracks work correctly with my various different smart playlists. In rare instances I'll also need to tweak the artist name to fit with the existing tracks in my library. Sometimes the album or track names have extra info that I don't care about and will delete. And TV show metadata is usually a mess and needs quite a bit of editing.
retSava 5y ago
It could be a form of "look, this file is X large for Y minutes, that's much more than Z, so it must be better!". I have a rising suspicion that some game companies with fluid ethics do this - avoiding to optimize and strip unused content, in order to inflate game size. "Wow, it's 102 GB, the game must be huge with boatloads of content!" (ie huge == higher chance of I'm getting my moneys worth). Which in turn becomes a problem with the latest generation consoles that have quite little drive space (Playstation ca 625 GB).
- dijit 5y ago
  I used to work very hard to push game binary sizes down because it limits the ability for our customers to actually play the game if the patch sizes are too large (though, it must be noted a large part of the company is entirely apathetic to this), but nobody is inflating the sizes intentionally. As much as people like to hate on consoles gamers, it's predominantly console "TRCs" which put limits on the size of games, that's the only time the company really cares about the sizes of games.
  - xenadu02 5y ago
    Download size is a "tragedy of the commons" situation. The overall size usually isn't owned by anyone and each contribution to increasing the size is usually small so monitoring it daily or weekly doesn't help. It is only when you are able to compare the size 1 month, 6 months, 12 months ago that a large jump can be observed - one accomplished by lots of tiny 0.1% increments. But even if you do notice that and file bugs what team in their right mind would spend time trying to reduce their own component's size by 2% when they could spend that time on features or bug fixing instead? And if you asked the majority of their users would agree - "F'k the 20MB, fix bug XYZ/finally implement feature ABC". Despite each individual decision along the way being arguably the correct decision the product still adds up to +30% every year.
    - rrrrrrrrrrrryan 5y ago
      "Never do any download size optimizations" is just as silly as "shave off 20MB at the expense of implementing a much-needed feature." Usually there's some ultra low-hanging fruit that everyone knows about, and if download size has become an issue, a bit of time should absolutely be allocated to basic housekeeping tasks as long as the product is supported.
boesboes 5y ago
This is what happens when you teach developers 'storage/hardware/compute is cheap' if you ask me. That plus the lack of interest in Apple Music development in general. (I cannot imagine that shitty music player received much love over the pas years. Still better then spotify though.) Funny side note: I recently made it's frontend crash. Turns out it _is_ a JS frontend after all. I suspected as much because of how slow & slugish it is, but I got an actual JS error & it fell back to the old table interface
- fredley 5y ago
  If you're buying your storage from Apple it is not cheap!
- kall 5y ago
  I believe they just fixed this (after how many years?) by moving Music.app away from webviews to native views in macOS 12.2. I wouldn't be surprised to still see a JavaScript error in there though, or maybe a Java error because it probably still runs on WebObjects.
- hans1729 5y ago
  > Still better then spotify though Surely you are talking about different clients than I have on i/macOS? With Apple Music running on my MacBook, I couldn’t even control the player on the respective iOS app from the couch. It was insultingly trashy UX, and I’m deep, deep into apples ecosystem. My reaction was “what a joke, guess I have to use Spotify”.
  - basisword 5y ago
    Apple Music could lack 90% of Spotify’s features, but Spotify will never get me back to their awful desktop UI. It looks like it’s made for toddlers. Full screen on an artist page I don’t even see 5 songs because they have this stupid big banner section taking up 2/3 of the screen. Throw in their spamming of podcasts to me and the whole desktop experience is a mess. Apple Music has its issues but at least the UI is kind of ok. That’s how low Spotify has set the bar which is a shame because their UI was great for about a decade and then they just set it on fire.
MarcoZavala 5y ago
nayuki 5y ago
I worked with the FLAC format and it also recommends padding to make it easier to edit metadata. I think libflac reserves 4 KB by default. > PADDING: This block allows for an arbitrary amount of padding. The contents of a PADDING block have no meaning. This block is useful when it is known that metadata will be edited after encoding; the user can instruct the encoder to reserve a PADDING block of sufficient size so that when metadata is added, it will simply overwrite the padding (which is relatively quick) instead of having to insert it into the right place in the existing file (which would normally require rewriting the entire file). -- https://xiph.org/flac/format.html#format_overview https://xiph.org/flac/format.html#format_overview
- hbn 5y ago
  The article mentions this. It's just half a megabyte seems like a lot for metadata, especially since it's been doing this for so many years, when storage was more expensive
  - nayuki 5y ago
    The article explained the reason for the AAC file padding. I'm pointing out that other formats like FLAC (not mentioned in the article) also adopt this strategy.
  - throwntoday 5y ago
    Depends if the space is utilized for album art which can easily exceed 0.5MB
    - kadoban 5y ago
      If it's album art then it doesn't seem big _enough_. Either way it's a bit odd of a size. Maybe it was for album art back when resolutions were lower and it was enough.
      - iggldiggl 5y ago
        > If it's album art then it doesn't seem big _enough_. Doesn't it? Unless you're embedding print-quality artwork or more than just the front cover, I would have thought that 0.5 MB was plenty…
CharlesW 5y ago
The key to understanding this issue seems to be "-movflags +faststart". The TLDR is that Apple apparently isn't "fast-starting" their MPEG-4 files before distribution. This became a thing when distributing QuickTime Movies on the internet became a thing (it's not an issue with random-access media), because one needed Movie metadata at the front of the file in order to support progressive playback. Because the MPEG-4 file format is effectively the QuickTime Movie file format, the need to put metadata at the front of the file continues if you want viewers/listeners to be able to play files as they're downloading. That Apple isn't performing this extremely trivial pre-distribution process is extremely curious. It makes me wonder if this "common knowledge" was lost along the way, or if the people who would know this kind of super-obvious production step just aren't the same people in charge of Apple Music standards. For anyone curious about what fast-start implementations look like: https://github.com/FFmpeg/FFmpeg/blob/master/tools/qt-faststart.c https://github.com/FFmpeg/FFmpeg/blob/master/tools/qt-fastst... https://github.com/kanongil/node-faststart https://github.com/kanongil/node-faststart
- thrdbndndn 5y ago
  What? Faststart just means the metadata is at the front of the file, which these 500KB padded m4a files do have. They just have excessive paddings between the metadata and the content stream. The author used this flag in FFMPEG because.. well, despite the main goal is to shrink the padding, you still want to have metadata at the beginning.
  - CharlesW 5y ago
    > Faststart just means the metadata is at the front of the file, which these 500KB padded m4a files do have. You're correct in the sense that having metadata at the start of the file means that these files are ready for progressive download/playback, albeit with a chunk of unnecessary data transfer. But the other important part of the "faststart" process is that you get what used to be called a "flattened" file, where the data is contiguous — metadata is followed immediately by compressed media data. (Tools for QuickTime Movies also compressed the 'moov' header, but I'm not sure if that's supported in MPEG-4.)
outside1234 5y ago
Why didn't they just put the metadata at the end so it could expand or contract?
- matthews2 5y ago
  "placing the metadata block at the end of the file means you must download (or read from local storage) the entire song before you can play it."
  - alpaca128 5y ago
    How does the lack of album art prevent playback? And local music apps already build their own library so they don't have to scan all files for metadata, I don't see how the location in the file changes anything.
userbinator 5y ago
You can’t make changes to the metadata (e.g. change the spelling of an artist’s name) without reassembling the entire file to recalculate the offsets. Split the file after the metadata block; change the data inside the metadata block (possibly changing its size); add the difference between the old and new size to all the offsets in it; recat the two pieces together. You could even do this "streamingly", to inject album art etc., since you know what size the added content will be. Simply add the diff-offsets to the right fields as they get streamed out. The above solutions didn't take much thought to come up with. I wonder why no one at Apple thought of that (especially the latter)?
- rootusrootus 5y ago
  > The above solutions didn't take much thought to come up with. I wonder why no one at Apple thought of that (especially the latter)? The quintessential HN comment!
- cogman10 5y ago
  This is the sort of thing that also seems crazy rare to need to fix. Ok, so you need to reassemble a file and recalculate offsets when an artist changes their names... so what? How often does that actually happen? Do people that download your music CARE that the meta data reflects an old/wrong spelling? Even the argument of "Well, they need to download the whole file before they can see the metadata" seems really weak. If someone is streaming the music, why not stream the metadata separately from the data? Why do those two things HAVE to be together? Heck, why not have a metadata "db" (ala plex) instead of insisting that stuff be bundled on the media itself? Just seems like a bad solution all around.
  - iggldiggl 5y ago
    > Heck, why not have a metadata "db" (ala plex) instead of insisting that stuff be bundled on the media itself? Because that isn't portable and then a different faction will be screaming "vendor lock-in". The metadata inside the media file itself is in a standard format that anybody can read, and storing it inside the file also ensures that it cannot become separated from the file it's belonging to. Besides, any reasonable kind of software involving any kind of media library will already be keeping its own metadata database (and that includes iTunes/Apple Music), because rescanning the whole library on each program startup would be ridiculously inefficient (all the more so historically when hard disks were more common). But it can't be the sole source of truth because see above – people who still keep a local library of music around might want their media file collection to be interoperable with other software, too.
punnerud 5y ago
Sound just like how SalesForce is storing data, and charging the customers high prices for the data.
banana_giraffe 5y ago
I do wonder if this was done because Apple noticed people change Album artwork more than any other metadata, and wanted to leave room so such an action would generally be quick, even on slower drives.
- mr_toad 5y ago
  Leaving room might also reduce file fragmentation.
sergiofuente01 5y ago
WFHRenaissance 5y ago
Just in case they want to make the song a _bit_ longer.
londons_explore 5y ago
The iTunes store launched in 2003, when most users were on dialup. File sizes of music was critical to the success of the service. There is no way they would have had 500 kilobytes of empty space back then. So when did this get added?
- d2wa 5y ago
  The earliest confirmed case is 2010. The author/I couldn’t get hold of any earlier sample files. Do let me know if you happen to have a local copy of some older files.
mshockwave 5y ago
slightly tangent: is there any reason OP preferred "," over "."? It looks so disturbing to me to be honest.
- turkeywelder 5y ago
  That's how most of Europe do decimal places, using commas instead of full stops.
  - goosedragons 5y ago
    I get it and it's probably done out of habit but in English it's just weird. AFAIK no English speaking majority area does it either.
- dragonwriter 5y ago
  Probably because the OP is from one of the many parts of the world where “,” is the decimal point and “.” is the thousands separator.
- kencausey 5y ago
  https://en.wikipedia.org/wiki/Decimal_separator https://en.wikipedia.org/wiki/Decimal_separator (i.e. not everyone uses a period)
- lm28469 5y ago
  Yes, he's from Denmark: https://en.wikipedia.org/wiki/Decimal_separator https://en.wikipedia.org/wiki/Decimal_separator
  - tveyben 5y ago
    Well Oslo is not in Denmark, but in Norway (a different country). I (from Denmark) find it "disturbing" to see `.´ as the decimal point, AM/PM for time, as well as writing the DAY before the MONTH (MM/DD-YYYY). https://m.xkcd.com/927/ https://m.xkcd.com/927/ https://www.ctrl.blog/about/ https://www.ctrl.blog/about/ "Ctrl blog (“Control blog”) is the developer-focused blog of Daniel Aleksandersen based in Oslo, Norway."
zxcvgm 5y ago
Just like the author, I too am quite particular about empty space in my MP3 files. When I was ripping my CD collection, I religiously tagged the MP3 files with ID3v1. Later on, I had some tracks whose titles were just a tad longer than 30 chars so I had to use ID3v2 for those and I noticed the file size grew by _a lot_. Frustrated by this, I opened them in a hex editor and learnt that ID3v1 was a fixed format of 128 bytes, but v2 was variable. I also found out that the software had added a 4KB zero-byte padding to the v2 tag, which was "necessary" because the tag is now at the front of the file, and this padding allows more tag data to be added easily later on. I tried various ID3 tagging software at that time and all of them added a padding. So I learned about the tag format and wrote a tagger myself that didn't add any padding. It was a great learning experience, and I managed to shave those useless zero bytes from my MP3s.
- folkrav 5y ago
  Unless I had a very large library or very limited storage space and no way to expand, I'm having a hard time understanding why this would objectively really matter at the scale of a personal MP3 library. We're talking about a tiny bit under 1GB of additional data per million individual tracks. Must have been pretty fun tracking this down, but I'm curious as to why you'd go through all this trouble. Storage is cheap, my time is not haha.
  - tommi 5y ago
    It's all about how you value your time. These kind of quests are usually very valuable learning tool and fun. I have learned a lot with hobby projects which didn't create any value as end products but were valuable to me.
    - exfascist 5y ago
      The underappreciated joy of yack shaving.
      - RosanaAnaDana 5y ago
deleted 5y ago
[deleted]
fredoralive 5y ago
Because I was trying to distract myself from stuff I looked at some files in a hex editor, and really old DRM AAC / M4P files from iTunes (still have a few around...) don't seem to have the same huge "free" padding block at the start of them (you can still see smaller "free" chunks, so they don't seem to be hidden by the encryption). Which is weird. DRM iTunes Store files were 128kbs, whilst non-DRM ones are 256kbs, as beyond removing DRM one of the selling points of what was called iTunes Plus at the time was better quality. So it's possibly back in circa 2009 someone made a fuckup with the encoding settings and no-one has noticed since. Or its some extremely weird conspiracy to sell larger iPods. Or perhaps they wanted to make the filesizes just a bit bigger so that iTunes Plus files felt like quality, like the way expensive products have metal weights added just to make them feel heavier and more solid.[1] [1] For avoidance of doubt, this last suggestion may be what is known as "humour".
- bombcar 5y ago
  Or the DRM/encryption removed the zero’d bytes? Most encryption algorithms also compress.
  - giantrobot 5y ago
    You're not going to further compress the AAC track. Also the iTunes DRM operated at the track level. The audio track in the otherwise normal MP4 file was encrypted AAC data. All the metadata atoms and file header were all unencrypted.
RandomWorker 5y ago
Bigger is better, it’s a larger file size so there must be more quality. It works well for everything else. :)
Animats 5y ago
If only Apple had some way to store metadata for a file separately from the content. Something like files with a "data fork" and a "resource fork", maybe.
- watersb 5y ago
  Or even if there was a way for them store an image, like album art, as a file in a filesystem. They could keep a folder with multiple files... That might be confusing, though. Too bad they don't have a way to show a directory as a single "package" in the Finder. I can imagine that would be useful for a lot of things.
- ragingrobot 5y ago
  They ditched the concept about ten years ago. Being out of the loop I had to look up if APFS even supported them anymore, and in doing so, found opinions on two ends of the spectrum: the concept was the best thing ever, or one of the most detestable features. I guess no one really understood how to use them anymore and added to it's demise.
  - saagarjha 5y ago
    Resource forks are still used for transparent compression, which is heavily used by macOS system files and when decompressing certain archives (e.g. Xcode XIPs).
- noisem4ker 5y ago
  The closest there is for media files: http://m-tags.org/ http://m-tags.org/
daniel_iversen 5y ago
At first I thought it was some sort of fingerprinting for anti-piracy (which seems extreme), but seems like its just to store potential future album art :)
watersb 5y ago
Two complaints I have with iTunes. One is that it stores a "play count", the number of times you've played a song, directly in that song file. So it's always re-writing the source file of the track in the library. That would be only mildly irritating -- radically blowing up the size of system backups, for instance -- but for the fact that it routinely corrupts the new song file stream. I see so much bit rot in my iTunes audio files -- and nowhere else -- that the stupidity of not simply keeping some small database of play count veers over into uselessness. - The second complaint is that they decided that any file I had ripped from my CDs were pirated, and therefore would require an annual fee for me to keep. I understand that's a concession they agreed to from music industry in order to roll out their "iTunes Cloud" stuff. But yes, I bought more than 400 CDs new and yes, I still have all of them, and indeed, I never loaned them out to anyone else (no one asked). - After a while, I just set my iTunes audio files to read-only, and a to-do item from ten years ago is to go through and re-encode my physical CDs. Still haven't done that, yet. Stopped using iTunes, instead. Still need to rip them discs...
- d2wa 5y ago
  > One is that it stores a "play count", the number of times you've played a song, directly in that song file. So it's always re-writing the source file of the track in the library. It writes ratings to the file, but not play count. I don't believe any player does that.
  - watersb 5y ago
    Oops. It's been a long time... Ratings (5 stars!!), not play count. Thanks!
    - iggldiggl 5y ago
      Does it? My personal experience is that both play count and ratings are only stored inside the iTunes database and not inside the media files, too. (And a cursory search does indeed bring up various people searching for workarounds to that in order to transfer the rating from iTunes to some different software…)
boondaburrah 5y ago
Could this have anything to do with how FairPlay DRM was implemented on iTunes Store purchased tracks back when it existed?
- d2wa 5y ago
  Probably not.
josephcsible 4y ago
> You can’t make changes to the metadata (e.g. change the spelling of an artist’s name) without reassembling the entire file to recalculate the offsets. Isn't this a really, really infrequent operation? And aren't hard drives fast enough these days that reassembling the entire file doesn't even take that long?

407 points by mritzmann 5y ago

Glad to hear I'm not the only one who stuffs as much music into their phone as possible :) Not an apple user, but I'd also enjoy some sudden extra 6% for sure.

deleted 5y ago
[deleted]

dwighttk 5y ago

Apple’s album art has been janky for me for 20 years. I’m sure it would be less noticeable if I had mostly mainstream music tastes, but after years of doing album art manually, Apple screwed it all up multiple times and I stopped caring as much about fighting around the time I gave in and started streaming more music.

anentropic 5y ago
Yeah it seems to randomly "forget" it
reaperducer 5y ago
Apple’s album art has been janky for me for 20 years My wife and I sync music from the same Apple Music library. On her iPhone, the album artwork is completely random. On my iPhone, it's always correct. No amount of wiping the phone, or even upgrading to new phones, will change this. Apple Music just hates her.
- lukifer 5y ago
  I feel your pain: I have a large and meticulously tagged collection, and when I upgraded to a new iPhone, it seems to have hit "shuffle" on every single album art, even after I nuked it all and did a fresh sync. It's incredibly bizarre.
- ungamedplayer 5y ago
  This is going to sound weird, but is your wifes phone set to a non US english (even something like australian/british english) language ? I found the same problem with my phone a long time ago for a non US english account. Once i had that configured differently than what my setting was on the app store it would do all kinds of stupid things with the artwork.
  - rrrrrrrrrrrryan 5y ago
    This is hilarious.
creeble 5y ago
Yes, one of my favorite jankinesses is that iTunes would put a timestamp in the jpeg header of the embedded artwork for every m4a file, ensuring that a hash of the artwork (for a library system that tried to minimize duplicate artwork) would always be unique. So you’d have a visually-identical but duplicate artwork file for every song on the album.

fredley 5y ago

Taken alone this might be unfortunate, but given Apple's long-standing trend of upselling storage at hugely inflated prices it's pretty damning.

jamil7 5y ago
For Apple Music it's probably a case of Hanlon's razor, it's been buggy and busted forever.
- willis936 5y ago
  What if the incompetence is maliciously decided upon? Hanlon's razor works for individuals, but falls apart for larger institutions.
  - Ken_At_EM 5y ago
    I believe that you may be significantly underestimating the incompetence of most organizations.
  - jklein11 5y ago
    If all of the individuals are acting without malice, how could the institution act with malice? Isn't the institution just the collective will of the individuals? I could see it playing out like this, incompetence causes the problem, incompetence fails to identify the problem, incompetence fails to fix the problem.
    - deleted 5y ago
      [deleted]
    - willis936 5y ago
      That betrays the cooperative principle. Such an institution could not survive.
    - 8organicbits 5y ago
      > If all of the individuals are acting without malice, how could the institution act with malice? Isn't the institution just the collective will of the individuals? I think we are on an unproductive tangent, but these are quite important questions. An institution doesn't have its own free will, so I don't think I can claim it can have "intent to cause harm", but it can certainly cause harm. An institution is not just a collection of people, it is also the business processes and policies. While these are created by people within the institution, they stick around over time. As the world changes around the organization, well intentioned policy can begin to harm. Individual employees following policy and normal business practice (i.e. just doing their jobs) can behave maliciously without their own intent to do so (sorry, my hands are tied). An institution needs not only non-malicious members, it needs to constantly re-evaluate its practices. Importantly, when harmful outcomes are observed the institution must re-evaluate and adjust, otherwise the harm will continue. It's not enough for members to conduct their own behavior without malice, they must also observe outcomes and actively fight against the inertia of existing policy.

bombcar 5y ago

It would seem to me (probably naïveté) that if you have a variable part of a file the variable part should come after the fixed parts …

seanalltogether 5y ago
> For example, placing the metadata block at the end of the file means you must download (or read from local storage) the entire song before you can play it. To avoid this, encoders tend to place it before the much larger multimedia stream block. The metadata block refers to absolute positions inside the multimedia stream block measured as an offset from the start of the file. You can’t make changes to the metadata (e.g. change the spelling of an artist’s name) without reassembling the entire file to recalculate the offsets.
- bombcar 5y ago
  I know local storage can seek to a location in a file without reading the whole thing (ZIP files start with a pointer to the metadata directory which is at the end of the file IIRC), so then all you need is a download system that lets you grab the first block of the file, and then ask for a later block without the middle blocks.
  - pavon 5y ago
    Back in the HDD days, loading music metadata was far from instantaneous even with the metadata in the front. Putting it at the back would have doubled the time needed for the UI to update. Now, that SSDs are more ubiquitous though it might be time to revisit that decision.
  - eropple 5y ago
    This requires multiple requests (or did before QUIC, things may be better now) and a server expecting range requests. It's much more reliable, considering the general mess of web requests, to put everything at the front. It was even more reliable in 2005 to do so.
- JKCalhoun 5y ago

davidhyde 5y ago

Ripping from cd reserves 0.05% (about 5kb) for metadata. I can imagine some communication breakdown where someone thought they meant 5% (about 500kb) when specifying the number 0.05 with a % next to it. You see percentage mixups all the time.

cdot2 5y ago
In the article he describes how the 500kb was originally used for album art but when Apple started storing that separately they didn't remove the space for it in the music files
- anentropic 5y ago
  It describes the author's conjecture that maybe it was for album art, but actual reason is unknown
  - EricE 5y ago
    Since the album art happens to fit *perfectly* into the space, it's a pretty solid conjecture.
    - etchalon 5y ago
      Album Art images are not exactly 500K. The percent mixup conjecture is just as evidence based as the Album Art conjecture.
      - mlyle 5y ago
        Percent mixup doesn't make sense when it's 500k whether it's a short or long track.
- Melatonic 5y ago
  I agree - 0.05% or whatever who cares - but at very large library sizes 500kb could start to add up. Then again I question who in the first place is keeping very large libraries of apple music files......

dpcx 5y ago

With the advent of streaming music as popular as it is (and surely Apple had to see that becoming the trend), this seems largely like a non-issue from a storage perspective. In fact, it's really only costing Apple more money in bandwidth because they still have to transmit that data - though I'd bet it compresses extremely well.

fignews 5y ago
Apple Music stores music locally. On my 512GB iPhone it’s the number one consumer of space
- Cupprum 5y ago
  Depends whether you download it or just stream it.
- EricE 5y ago
  And by default it works like cache. If you need space the music files are the first to go since they can just be re-downloaded.
basisword 5y ago
Unless they have unlimited data the end user is also paying directly for this, not just Apple.

londons_explore 5y ago

In 2022, we shouldn't be reserving any area of a file as 'spare space' like this. On the very rare occasion you adjust the artists name in a music file, the user expects the whole file will be rewritten. So just rewrite the whole file. Whats next? Photoshop only writing out a quarter of an image when I edit my ex out of a nice photo? MS Word only touching a few bytes of a 100 page document when I make a heading bold?

Cupprum 5y ago
> In 2022, we shouldn't be reserving any area of a file as 'spare space' like this. I completely understand your point, but maybe it would be a breaking change.
- londons_explore 5y ago
  It wouldn't be. This spare space is entirely optional in the file format specification, and it's up to the tool that makes the file if it wants to include it or not.
dotancohen 5y ago
> In 2022, we shouldn't be reserving any area of a file as 'spare space' like this. In 2022, we should have file formats that are not naive of the underlying filesystem. I store my text notes in Git, but I also have two LibreOffice documents in there because org-mode doesn't handle their contents well. It would be nice of only 5% of the file had to be rewritten when I change a single word, rather than the current 91% of the file. A 5% hit to storage for a 91% reduction each time I update it would be a great trade off.
- nyanpasu64 5y ago
  One option is to store files as a database like SQLite, which I assume is designed around not rewriting the whole file on every change. For example Audacity 3.x does this. However SQLite stores multiple files on disk for crash persistence, complicating matters. But then again so does Audacity 2, and Microsoft Office to an extent (file locking rather than data integrity). Microsoft Word used to only append changes to the document on save rather than rewriting the whole file, but this was disabled since if you deleted text and saved the file, it remained in the document. https://www.cnet.com/culture/microsoft-disabling-word-2003s-fast-save-feature/ https://www.cnet.com/culture/microsoft-disabling-word-2003s-...

ajsnigrutin 5y ago

How often do users change the metadata of music bought from Apple Music? When ripping stuff by hand, this is understandable.. you make a typo, want to add a year, do some locale changes to add local characters, etc... so in this case i see a possible need to waste 5 kB of space to save a couple of seconds after an edit. But with downloadad music with all the metadata (hopefully) correctly set, even 5kB is a waste of space.

alan-hn 5y ago
Isn't 0.5MB 500 KB? Not 5? Or are you referring to something else
- SketchySeaBeast 5y ago
  They are saying that even a much smaller amount of memory than what they are wasting is a waste.
- ajsnigrutin 5y ago
  From the article: > If you rip a CD with Apple Music using the Apple AAC Encoder (the default option), it will reserve approximately 5 kB of free space inside each file for this purpose. I was saying that even this is too much, and 500kB is 'way way too much'.
- lelanthran 5y ago
  > Isn't 0.5MB 500 KB? Not 5? Or are you referring to something else The article said that the default is 5KB but Apple uses 500KB, hence the poster is saying that even 5KB is overkill.
thought_alarm 5y ago
I always edit the genre so that the tracks work correctly with my various different smart playlists. In rare instances I'll also need to tweak the artist name to fit with the existing tracks in my library. Sometimes the album or track names have extra info that I don't care about and will delete. And TV show metadata is usually a mess and needs quite a bit of editing.

retSava 5y ago

It could be a form of "look, this file is X large for Y minutes, that's much more than Z, so it must be better!". I have a rising suspicion that some game companies with fluid ethics do this - avoiding to optimize and strip unused content, in order to inflate game size. "Wow, it's 102 GB, the game must be huge with boatloads of content!" (ie huge == higher chance of I'm getting my moneys worth). Which in turn becomes a problem with the latest generation consoles that have quite little drive space (Playstation ca 625 GB).

dijit 5y ago
I used to work very hard to push game binary sizes down because it limits the ability for our customers to actually play the game if the patch sizes are too large (though, it must be noted a large part of the company is entirely apathetic to this), but nobody is inflating the sizes intentionally. As much as people like to hate on consoles gamers, it's predominantly console "TRCs" which put limits on the size of games, that's the only time the company really cares about the sizes of games.
- xenadu02 5y ago
  Download size is a "tragedy of the commons" situation. The overall size usually isn't owned by anyone and each contribution to increasing the size is usually small so monitoring it daily or weekly doesn't help. It is only when you are able to compare the size 1 month, 6 months, 12 months ago that a large jump can be observed - one accomplished by lots of tiny 0.1% increments. But even if you do notice that and file bugs what team in their right mind would spend time trying to reduce their own component's size by 2% when they could spend that time on features or bug fixing instead? And if you asked the majority of their users would agree - "F'k the 20MB, fix bug XYZ/finally implement feature ABC". Despite each individual decision along the way being arguably the correct decision the product still adds up to +30% every year.
  - rrrrrrrrrrrryan 5y ago
    "Never do any download size optimizations" is just as silly as "shave off 20MB at the expense of implementing a much-needed feature." Usually there's some ultra low-hanging fruit that everyone knows about, and if download size has become an issue, a bit of time should absolutely be allocated to basic housekeeping tasks as long as the product is supported.

boesboes 5y ago

This is what happens when you teach developers 'storage/hardware/compute is cheap' if you ask me. That plus the lack of interest in Apple Music development in general. (I cannot imagine that shitty music player received much love over the pas years. Still better then spotify though.) Funny side note: I recently made it's frontend crash. Turns out it _is_ a JS frontend after all. I suspected as much because of how slow & slugish it is, but I got an actual JS error & it fell back to the old table interface

fredley 5y ago
If you're buying your storage from Apple it is not cheap!
kall 5y ago
I believe they just fixed this (after how many years?) by moving Music.app away from webviews to native views in macOS 12.2. I wouldn't be surprised to still see a JavaScript error in there though, or maybe a Java error because it probably still runs on WebObjects.
hans1729 5y ago
> Still better then spotify though Surely you are talking about different clients than I have on i/macOS? With Apple Music running on my MacBook, I couldn’t even control the player on the respective iOS app from the couch. It was insultingly trashy UX, and I’m deep, deep into apples ecosystem. My reaction was “what a joke, guess I have to use Spotify”.
- basisword 5y ago
  Apple Music could lack 90% of Spotify’s features, but Spotify will never get me back to their awful desktop UI. It looks like it’s made for toddlers. Full screen on an artist page I don’t even see 5 songs because they have this stupid big banner section taking up 2/3 of the screen. Throw in their spamming of podcasts to me and the whole desktop experience is a mess. Apple Music has its issues but at least the UI is kind of ok. That’s how low Spotify has set the bar which is a shame because their UI was great for about a decade and then they just set it on fire.

MarcoZavala 5y ago

nayuki 5y ago

I worked with the FLAC format and it also recommends padding to make it easier to edit metadata. I think libflac reserves 4 KB by default. > PADDING: This block allows for an arbitrary amount of padding. The contents of a PADDING block have no meaning. This block is useful when it is known that metadata will be edited after encoding; the user can instruct the encoder to reserve a PADDING block of sufficient size so that when metadata is added, it will simply overwrite the padding (which is relatively quick) instead of having to insert it into the right place in the existing file (which would normally require rewriting the entire file). -- https://xiph.org/flac/format.html#format_overview https://xiph.org/flac/format.html#format_overview

hbn 5y ago
The article mentions this. It's just half a megabyte seems like a lot for metadata, especially since it's been doing this for so many years, when storage was more expensive
- nayuki 5y ago
  The article explained the reason for the AAC file padding. I'm pointing out that other formats like FLAC (not mentioned in the article) also adopt this strategy.
- throwntoday 5y ago
  Depends if the space is utilized for album art which can easily exceed 0.5MB
  - kadoban 5y ago
    If it's album art then it doesn't seem big _enough_. Either way it's a bit odd of a size. Maybe it was for album art back when resolutions were lower and it was enough.
    - iggldiggl 5y ago
      > If it's album art then it doesn't seem big _enough_. Doesn't it? Unless you're embedding print-quality artwork or more than just the front cover, I would have thought that 0.5 MB was plenty…

CharlesW 5y ago

The key to understanding this issue seems to be "-movflags +faststart". The TLDR is that Apple apparently isn't "fast-starting" their MPEG-4 files before distribution. This became a thing when distributing QuickTime Movies on the internet became a thing (it's not an issue with random-access media), because one needed Movie metadata at the front of the file in order to support progressive playback. Because the MPEG-4 file format is effectively the QuickTime Movie file format, the need to put metadata at the front of the file continues if you want viewers/listeners to be able to play files as they're downloading. That Apple isn't performing this extremely trivial pre-distribution process is extremely curious. It makes me wonder if this "common knowledge" was lost along the way, or if the people who would know this kind of super-obvious production step just aren't the same people in charge of Apple Music standards. For anyone curious about what fast-start implementations look like: https://github.com/FFmpeg/FFmpeg/blob/master/tools/qt-faststart.c https://github.com/FFmpeg/FFmpeg/blob/master/tools/qt-fastst... https://github.com/kanongil/node-faststart https://github.com/kanongil/node-faststart

thrdbndndn 5y ago
What? Faststart just means the metadata is at the front of the file, which these 500KB padded m4a files do have. They just have excessive paddings between the metadata and the content stream. The author used this flag in FFMPEG because.. well, despite the main goal is to shrink the padding, you still want to have metadata at the beginning.
- CharlesW 5y ago
  > Faststart just means the metadata is at the front of the file, which these 500KB padded m4a files do have. You're correct in the sense that having metadata at the start of the file means that these files are ready for progressive download/playback, albeit with a chunk of unnecessary data transfer. But the other important part of the "faststart" process is that you get what used to be called a "flattened" file, where the data is contiguous — metadata is followed immediately by compressed media data. (Tools for QuickTime Movies also compressed the 'moov' header, but I'm not sure if that's supported in MPEG-4.)

outside1234 5y ago

Why didn't they just put the metadata at the end so it could expand or contract?

matthews2 5y ago
"placing the metadata block at the end of the file means you must download (or read from local storage) the entire song before you can play it."
- alpaca128 5y ago
  How does the lack of album art prevent playback? And local music apps already build their own library so they don't have to scan all files for metadata, I don't see how the location in the file changes anything.

userbinator 5y ago

You can’t make changes to the metadata (e.g. change the spelling of an artist’s name) without reassembling the entire file to recalculate the offsets. Split the file after the metadata block; change the data inside the metadata block (possibly changing its size); add the difference between the old and new size to all the offsets in it; recat the two pieces together. You could even do this "streamingly", to inject album art etc., since you know what size the added content will be. Simply add the diff-offsets to the right fields as they get streamed out. The above solutions didn't take much thought to come up with. I wonder why no one at Apple thought of that (especially the latter)?

rootusrootus 5y ago
> The above solutions didn't take much thought to come up with. I wonder why no one at Apple thought of that (especially the latter)? The quintessential HN comment!
cogman10 5y ago
This is the sort of thing that also seems crazy rare to need to fix. Ok, so you need to reassemble a file and recalculate offsets when an artist changes their names... so what? How often does that actually happen? Do people that download your music CARE that the meta data reflects an old/wrong spelling? Even the argument of "Well, they need to download the whole file before they can see the metadata" seems really weak. If someone is streaming the music, why not stream the metadata separately from the data? Why do those two things HAVE to be together? Heck, why not have a metadata "db" (ala plex) instead of insisting that stuff be bundled on the media itself? Just seems like a bad solution all around.
- iggldiggl 5y ago
  > Heck, why not have a metadata "db" (ala plex) instead of insisting that stuff be bundled on the media itself? Because that isn't portable and then a different faction will be screaming "vendor lock-in". The metadata inside the media file itself is in a standard format that anybody can read, and storing it inside the file also ensures that it cannot become separated from the file it's belonging to. Besides, any reasonable kind of software involving any kind of media library will already be keeping its own metadata database (and that includes iTunes/Apple Music), because rescanning the whole library on each program startup would be ridiculously inefficient (all the more so historically when hard disks were more common). But it can't be the sole source of truth because see above – people who still keep a local library of music around might want their media file collection to be interoperable with other software, too.

punnerud 5y ago

Sound just like how SalesForce is storing data, and charging the customers high prices for the data.

banana_giraffe 5y ago

I do wonder if this was done because Apple noticed people change Album artwork more than any other metadata, and wanted to leave room so such an action would generally be quick, even on slower drives.

mr_toad 5y ago
Leaving room might also reduce file fragmentation.

sergiofuente01 5y ago

WFHRenaissance 5y ago

Just in case they want to make the song a _bit_ longer.

londons_explore 5y ago

The iTunes store launched in 2003, when most users were on dialup. File sizes of music was critical to the success of the service. There is no way they would have had 500 kilobytes of empty space back then. So when did this get added?

d2wa 5y ago
The earliest confirmed case is 2010. The author/I couldn’t get hold of any earlier sample files. Do let me know if you happen to have a local copy of some older files.

mshockwave 5y ago

slightly tangent: is there any reason OP preferred "," over "."? It looks so disturbing to me to be honest.

turkeywelder 5y ago
That's how most of Europe do decimal places, using commas instead of full stops.
- goosedragons 5y ago
  I get it and it's probably done out of habit but in English it's just weird. AFAIK no English speaking majority area does it either.
dragonwriter 5y ago
Probably because the OP is from one of the many parts of the world where “,” is the decimal point and “.” is the thousands separator.
kencausey 5y ago
https://en.wikipedia.org/wiki/Decimal_separator https://en.wikipedia.org/wiki/Decimal_separator (i.e. not everyone uses a period)
lm28469 5y ago
Yes, he's from Denmark: https://en.wikipedia.org/wiki/Decimal_separator https://en.wikipedia.org/wiki/Decimal_separator
- tveyben 5y ago
  Well Oslo is not in Denmark, but in Norway (a different country). I (from Denmark) find it "disturbing" to see `.´ as the decimal point, AM/PM for time, as well as writing the DAY before the MONTH (MM/DD-YYYY). https://m.xkcd.com/927/ https://m.xkcd.com/927/ https://www.ctrl.blog/about/ https://www.ctrl.blog/about/ "Ctrl blog (“Control blog”) is the developer-focused blog of Daniel Aleksandersen based in Oslo, Norway."

zxcvgm 5y ago

Just like the author, I too am quite particular about empty space in my MP3 files. When I was ripping my CD collection, I religiously tagged the MP3 files with ID3v1. Later on, I had some tracks whose titles were just a tad longer than 30 chars so I had to use ID3v2 for those and I noticed the file size grew by _a lot_. Frustrated by this, I opened them in a hex editor and learnt that ID3v1 was a fixed format of 128 bytes, but v2 was variable. I also found out that the software had added a 4KB zero-byte padding to the v2 tag, which was "necessary" because the tag is now at the front of the file, and this padding allows more tag data to be added easily later on. I tried various ID3 tagging software at that time and all of them added a padding. So I learned about the tag format and wrote a tagger myself that didn't add any padding. It was a great learning experience, and I managed to shave those useless zero bytes from my MP3s.

folkrav 5y ago
Unless I had a very large library or very limited storage space and no way to expand, I'm having a hard time understanding why this would objectively really matter at the scale of a personal MP3 library. We're talking about a tiny bit under 1GB of additional data per million individual tracks. Must have been pretty fun tracking this down, but I'm curious as to why you'd go through all this trouble. Storage is cheap, my time is not haha.
- tommi 5y ago
  It's all about how you value your time. These kind of quests are usually very valuable learning tool and fun. I have learned a lot with hobby projects which didn't create any value as end products but were valuable to me.
  - exfascist 5y ago
    The underappreciated joy of yack shaving.
    - RosanaAnaDana 5y ago

deleted 5y ago

[deleted]

fredoralive 5y ago

Because I was trying to distract myself from stuff I looked at some files in a hex editor, and really old DRM AAC / M4P files from iTunes (still have a few around...) don't seem to have the same huge "free" padding block at the start of them (you can still see smaller "free" chunks, so they don't seem to be hidden by the encryption). Which is weird. DRM iTunes Store files were 128kbs, whilst non-DRM ones are 256kbs, as beyond removing DRM one of the selling points of what was called iTunes Plus at the time was better quality. So it's possibly back in circa 2009 someone made a fuckup with the encoding settings and no-one has noticed since. Or its some extremely weird conspiracy to sell larger iPods. Or perhaps they wanted to make the filesizes just a bit bigger so that iTunes Plus files felt like quality, like the way expensive products have metal weights added just to make them feel heavier and more solid.[1] [1] For avoidance of doubt, this last suggestion may be what is known as "humour".

bombcar 5y ago
Or the DRM/encryption removed the zero’d bytes? Most encryption algorithms also compress.
- giantrobot 5y ago
  You're not going to further compress the AAC track. Also the iTunes DRM operated at the track level. The audio track in the otherwise normal MP4 file was encrypted AAC data. All the metadata atoms and file header were all unencrypted.

RandomWorker 5y ago

Bigger is better, it’s a larger file size so there must be more quality. It works well for everything else. :)

Animats 5y ago

If only Apple had some way to store metadata for a file separately from the content. Something like files with a "data fork" and a "resource fork", maybe.

watersb 5y ago
Or even if there was a way for them store an image, like album art, as a file in a filesystem. They could keep a folder with multiple files... That might be confusing, though. Too bad they don't have a way to show a directory as a single "package" in the Finder. I can imagine that would be useful for a lot of things.
ragingrobot 5y ago
They ditched the concept about ten years ago. Being out of the loop I had to look up if APFS even supported them anymore, and in doing so, found opinions on two ends of the spectrum: the concept was the best thing ever, or one of the most detestable features. I guess no one really understood how to use them anymore and added to it's demise.
- saagarjha 5y ago
  Resource forks are still used for transparent compression, which is heavily used by macOS system files and when decompressing certain archives (e.g. Xcode XIPs).
noisem4ker 5y ago
The closest there is for media files: http://m-tags.org/ http://m-tags.org/

daniel_iversen 5y ago

At first I thought it was some sort of fingerprinting for anti-piracy (which seems extreme), but seems like its just to store potential future album art :)

watersb 5y ago

Two complaints I have with iTunes. One is that it stores a "play count", the number of times you've played a song, directly in that song file. So it's always re-writing the source file of the track in the library. That would be only mildly irritating -- radically blowing up the size of system backups, for instance -- but for the fact that it routinely corrupts the new song file stream. I see so much bit rot in my iTunes audio files -- and nowhere else -- that the stupidity of not simply keeping some small database of play count veers over into uselessness. - The second complaint is that they decided that any file I had ripped from my CDs were pirated, and therefore would require an annual fee for me to keep. I understand that's a concession they agreed to from music industry in order to roll out their "iTunes Cloud" stuff. But yes, I bought more than 400 CDs new and yes, I still have all of them, and indeed, I never loaned them out to anyone else (no one asked). - After a while, I just set my iTunes audio files to read-only, and a to-do item from ten years ago is to go through and re-encode my physical CDs. Still haven't done that, yet. Stopped using iTunes, instead. Still need to rip them discs...

d2wa 5y ago
> One is that it stores a "play count", the number of times you've played a song, directly in that song file. So it's always re-writing the source file of the track in the library. It writes ratings to the file, but not play count. I don't believe any player does that.
- watersb 5y ago
  Oops. It's been a long time... Ratings (5 stars!!), not play count. Thanks!
  - iggldiggl 5y ago
    Does it? My personal experience is that both play count and ratings are only stored inside the iTunes database and not inside the media files, too. (And a cursory search does indeed bring up various people searching for workarounds to that in order to transfer the rating from iTunes to some different software…)

boondaburrah 5y ago

Could this have anything to do with how FairPlay DRM was implemented on iTunes Store purchased tracks back when it existed?

d2wa 5y ago
Probably not.

josephcsible 4y ago

> You can’t make changes to the metadata (e.g. change the spelling of an artist’s name) without reassembling the entire file to recalculate the offsets. Isn't this a really, really infrequent operation? And aren't hard drives fast enough these days that reassembling the entire file doesn't even take that long?