A Syncing Ship - The iPod vs. Modern Software
This post was written by Ichika.
This is part two of a series about music collecting and listening in the modern era. You can read the first post here.
This post is less "why" you should use an iPod (it's a pretty good case against it, all things considered), but instead a project log of the hoops we had to jump through to make ours work with our library. We love ours to death, and we will be writing a post as to why eventually, but for now, I wanted to document our pitfalls so others could avoid them.
This is a long one, so strap in. TL;DR at the bottom if you just want to get straight to the advice.
The FLAC Problem
The most obvious, glaring issue is that the iPod does not support the FLAC file format.
For some reason, Apple has never actually properly supported FLAC in any of their music software. Even though they work in the Mac's Finder, the iOS Files app, and QuickTime Player, there's never been any way to add them an iTunes/Apple Music library, and thus no way to sync them to an iPod. Instead, Apple supports their own codec, known as the Apple Lossless Audio Codec, or ALAC.
This was the first problem - our entire library is in FLAC.
So now, I had two options - convert our entire library to ALAC, or figure out how to get FLACs on an iPod.
Luckily, the latter option was technically feasible - by using custom firmware.
Rockbox is a free, open-source custom firmware for dozens of different models of music players, including all six generations of iPod, both generations of iPod mini, and the first two iPod nanos. It's very powerful, coming with countless features that the stock firmware doesn't have, extensive customization, and even plugins like a Game Boy emulator. For our use case, though, it's something much less exciting that drew us to it:
FLAC support.
Normally, to put music on an iPod, you need to sync it with your library through software like ITunes or Music.app. This worked pretty well fifteen years ago, when iTunes wasn't a bloated mess and libraries were almost entirely MP3 files. But in 2024, iTunes is slow and buggy on Windows, the new Apple Devices app for Windows barely works, and Music.app is kind of pain - and, again, our whole library is FLAC, so we can't import them, and therefore can't sync them.
Rockbox gets around this by simply reading the filesystem. Instead of iTunes writing to a database, and organizing files and playlists around that, you can just plug your iPod into a computer, and drag the FLAC files to it like a flash drive. Then, you unplug the iPod, and you can browse the iPod's file system and play music files that way.
If you don't want to deal with the hassle of iTunes or Finder, it's the best way to go. And given that I was using a PC, I figured it made sense to skip iTunes altogether and just go with Rockbox. I install it to our iPod, and after waiting eight hours for all ~165GB of our music to copy over USB 2, I finally take it off the charger, plug in my headphones, and pick a song.
Unfortunately, I didn't love what I was(n't) seeing.
Stuck Between A Rock(box) and a Hard Place
Rockbox is old software.
Very, very old software - it started development the same year as the original iPod released, 2001.
This, unfortunately, shows, in some of its quirks. The first thing I noticed was that almost none of our songs were properly displaying their album artwork. The songs would play just fine, but the album art for 75% of our library just wouldn't load.
So I started digging. Doing a lot of research, reading a lot of old forum posts, when I came across the problem - due to its age, Rockbox was...a bit lacking, in terms of support for newer or larger image formats. A lot of modern JPEG files, for instance, are either too big, or in too new of a format, for Rockbox to read.
So, naturally, I had to figure out how I wanted to fix this.
I tried a few solutions - the first was seeing if Bliss, our automatic music organizer, could convert the album artworks into the right format for us. It choked, saying a lot of files were "too big to process". I still don't really understand the error - after all, I was pretty sure it's job was to make the images smaller in the first place - but I gave up on it pretty quick.
The good news is that I did find pretty much the perfect solution - the Album Art Extractor for Rockbox. A nearly 15-year-old piece of Windows software that did pretty much exactly what it says on the tin - it would read the album artwork from a song's metadata, extract it to a file, and convert that file into something that Rockbox could parse - for example, 300px BMP files - without actually changing the album artwork that was embedded into the file. I configured it exactly the way I wanted - 300px by 300px images, BMP image format, named 'cover.bmp' - and pointed it at the music files on the iPod. About an hour later, it had extracted the cover art from all of our music, and opening up Rockbox again, all of our music had the right artwork!
Unfortunately, the joy somewhat stops there.
Rockbox is really, really powerful. It can do a lot of things, but that comes at a cost - convenience, simplicity, and speed.
It was just...really, really slow and clunky.
Everyone's taste is different, but using Rockbox made me feel like our iPod had lost a lot of it's charm. It was slow to load our library, finicky to scroll with, harder to control, and wouldn't even properly display Japanese with the default font. I did find a theme I liked, but that wasn't enough to save it - we just don't like it.
In my opinion, it feels too utilitarian, and the lack of speed just made it kind of unfun to use. So, I set my sights on going back to the stock firmware.
Unfortunately, that leads us to...
The FLAC Problem -Reloaded-
So how am I gonna get all of my FLAC onto this iPod?
I did some thinking. The last thing I wanted to do, at the time, was to convert the entire library to a different format. After all, FLAC was a universal standard - did I really want to sacrifice the entire library for one device?
And then, a bit of searching later, and a possible solution fell right into my lap.
MediaMonkey is a media manager, in the same way that iTunes is. It can read your collection, manage metadata, build playlists, and be your default music player. It's pretty competent in that regard; I actually liked it a bit, even if the app was kinda slow. But its killer feature, for me? iPod sync support.
So I opened up iTunes, factory-reset the iPod, and decided to give MediaMonkey a shot. As soon as I re-connect the freshly-wiped iPod to the PC, it shows up in MediaMonkey's devices tab. So far so good.
I click into the iPod, and I see exactly what I want to see.
The "Sync Profile" tab allows you to set custom preferences for on-the-fly media conversion. MediaMonkey can detect if a file is incompatible with the iPod, and using a set of rules, can determine what file format to convert it to. And then, when it's done converting the file, it copies that file to the iPod, and your library is left entirely untouched.
It's everything we've wanted, we thought.
So, I set up the profile. The real star of the show was the rule that specified that any unsupported file format above 320kbps should be converted to Apple Lossless - this would make sure that all of our FLAC was converted to ALAC, which would then be synced with the iPod with no issues.
It was perfect.
So, I set MM to sync our entire library over, and I wait another eight hours for our music to copy over to the device, again.
I come back to the iPod later that night when the sync is done. We've now spent over 24 hours, at this point, trying to use our iPod. I'm relieved that this should be the end of it, and that I've found a solution to this weird problem. So, I plug my headphones back in, and I go to pick an album.
I press play.
It immediately skips the first song, and goes right into the second song.
Knowing that that's not how it works, I try to go back to the first song. It skips right back to the second song again. I try to skip forward, and forward, and then on the fifth song it skips right to the sixth song again. I try another album - it happens again, and again, and again.
Something went wrong in the conversion process somewhere.
After searching up our problem, reading tons of Reddit threads, and some forum posts, I came to find out that a pretty much any converter using FFMPEG under the hood causes a lot of problems for the iPod.
FFMPEG is a really, really useful piece of open-source software that's sole job is basically to convert and encode media files. It's really useful, and we've used it for a ton of things. The problem here is that, for whatever reason, FLAC files that were converted from FLAC to MP3, AAC, or ALAC using FFMPEG have issues on the iPod's firmware. The only solution to this, on Windows?
Use iTunes to convert everything over again.
Now, I really don't want to have to do this - using iTunes to convert things is a total pain, and then I have to discern the old ALAC files from the new ALAC files, and it just becomes a total mess to manage. So I do some digging as to why iTunes is the solution, and it turns out that Apple has their own AAC encoder, powered by QuickTime, given the shorthand "qaac".
FFMPEG, and by extension, MediaMonkey, can actually use qaac, but in order to use it, it requires using a custom build of FFMPEG, fiddling with a ton of command line options, and I wasn't really in the mood to deal with those. Luckily, I caught wind of a piece of software named XLD that used the QuickTime libraries.
Reluctantly, I sighed - I knew I'd have to do manual conversion on the entire library, and accepted my fate, and decided to look at XLD.
One, tiny problem - it was Mac only.
XLD is a program designed entirely for converting between lossless formats, and it does a really great job. It uses Apple's QuickTime libraries under the hood, too, so it's basically the same as iTunes converting the file itself. This, theoretically, would guarantee perfect iPod compatibility.
So now, I had to make another decision - there are two Macs that we own. Which one was the right tool for the job?
The fastest option is our M1 MacBook Air. Connectivity would be kinda difficult, since connecting our hard drive with our collection to it would be a total pain without a USB-A port; but it was an option. The easier option is the Power Mac G5 - it's period-accurate, runs iTunes, has USB 2, the whole nine yards. But it's slow - really slow. And really loud. And really hot.
As fun as the Power Mac G5 option sounded, it also seemed pretty impractical. Waiting for XLD to convert everything on the G5 would take forever, use a ton of power, and turn the room into a sauna. So, using some USB hub trickery, I hook up our USB hard drive to the MacBook Air, run XLD, and convert a few test files.
And it was a success! It spat out a few new ALAC files, that played well and sounded great. Everything was looking up...until I looked at the metadata.
Not to seem too egotistical, but I figured a good test was on the Leo/need cover of "Teo". In the artist tag, there should be "Hoshino Ichika & Hatsune Miku"...but the artist only said "Hatsune Miku". I agree that she takes priority here, but after opening the file in MusicBrainz, there was no remnant of the Hoshino Ichika tag at all. I tested several other songs with multiple artists, and sure enough, XLD was scrubbing all of them. If XLD wanted to ruin our metadata, then we couldn't use it.
I was getting kind of desperate, and honestly kind of exhausted, until a friend of ours suggested we use something called dbPoweramp to do our music conversion. I played around with it, and found out that the Mac version also uses the QuickTime libraries. I ran the same test files through dbPoweramp, and the resulting ALAC files seemed to have all of the metadata intact. This was a good step.
I then, very carefully, had to consider the weight of what I was about to do. I was about to move our entire music library from our hard drive to our MacBook, convert every single FLAC to ALAC, and then delete the old FLACs, because we can't afford 340GB of space just for music on this laptop. I did some triple-checking that ALAC was well-supported in apps that weren't made by Apple, but it turns out ALAC was made open-source 13 years ago, which means that pretty much every piece of modern music software supports it. It became clear to me that ALAC was actually more compatible with our music library than regular FLAC.
Taking a deep breath, I copied over all of the FLAC from our external hard drive to the Mac, set dbPoweramp to convert it all overnight, and went to bed.
The Great Metadata Wrangling Of 2024
I woke up the next day, ready to get back to finishing up organizing our library. I check the computer - the conversion was a total success. No errors, which was relieving, because I'd have been kind of upset if we were fast asleep while it was failing and all that time was wasted. I made sure everything made the jump from FLAC to ALAC smoothly, and then deleted the old FLAC files. All that was left to do now...was figure out the metadata situation.
See, something I didn't mention earlier is that I actually knew why XLD wouldn't properly handle multiple artists, and it has to do with how metadata is stored.
See, each part of a track's metadata - title, track number, album, artist, etc. - is a field that can be filled in, and attached to the file. One thing that's supported by almost everything is having multiple "artist" tags. Using the earlier example song, the Leo/need cover of Teo, instead of there being one artist tag for "Hoshino Ichika & Hatsune Miku", there would be two artist tags - one for "Hoshino Ichika" and one for "Hatsune Miku". Most music software would read these, and figure out how to properly organize them accordingly. In any other situation, this is actually probably the best way to do it. However, Apple software is weird, and behind the times, and has no support for multiple artist tags.
This is why the metadata in XLD appeared to be "wrong" - our library was using multiple artist tags in almost every file, and XLD was scrubbing the "excess" artist tags during the conversion process. dbPoweramp, however, did not strip the metadata, and instead simply converted the metadata alongside the file, making zero changes to any metadata during the conversion process.
This did, however, bring me to realize that I'd need to fix the metadata, manually, for every single song in our library.
I would have to go through our entire library, and combine all of the tags, so that Music.app (and, by extension, the iPod) would read them properly. This was a procedure that could take forever, but it was one we decided to do.
But first, a brief tangent for how Apple software handles artists.
As far as iTunes is concerned, every single 'artist' entry is it's own thing, and there no way to separate multiple artists. "Porter Robinson" and "Madeon" are their own artists. "Porter Robinson & Madeon" is a third, entirely different artist. "Porter Robinson feat. Madeon" is a fourth artist. If the artist tag is not identical to another artist tag, it is treated as a unique artist. The software simply has no way to handle featured artists or collaborations uniquely. This means, that if I don't want our tags to be a total mess, I have to figure out the best way to consolidate artists. The good news is, this is pretty simple - I just move the artist tags to the title of the song. "Miku" by "Anamanaguchi & Hatsune Miku" becomes "Miku (feat. Hatsune Miku)" by Anamanaguchi. It was a minor consistency issue, but I found this to generally work.
Anyways, back to fixing metadata.
So, initially, I'm incredibly daunted by the task of potentially manually fixing thousands of songs' worth of artist tags. I had resigned myself to the idea that I would be wasting a fair amount of our time trying to get something like this to work. The good news, however, was that I didn't need to worry about that at all, thanks to software we already had installed - Mp3tag.
Mp3tag, as it turns out, is in fact very powerful software. I had heard it could do batch-editing, but I wasn't sure to what extent - I very quickly found out, though. I looked around the menu bar for options, and found the "Actions" menu.
Which was exactly what I was looking for.
Actions in Mp3tag are essentially automation clips, similar to Apple's Shortcuts. You can configure any amount of steps you want an Action to take, and then apply them to however many songs you want. I dragged a test file into the Mp3tag window, and created an Action to do three things - combine duplicate 'artist' fields with " & ", combine duplicate 'albumartist' fields with " & ", and remove any comments (because they waste space) and genres (because we hate them) from songs. I selected my test song in the Mp3tag window, ran the Action, and it did exactly what I wanted it to do. It combined the separate "Hoshino Ichika" and "Hatsune Miku" tags into just one "Hoshino Ichika & Hatsune Miku" tag, and it scrubbed the genre from the file.
I immediately dragged our entire library into the software, selected all of it, and ran the Action on every file we had.
This saved me probably several dozen hours of work - but there was still work to be done.
Consistency Is Key
I figured that since I was already doing this metadata scrub, that I needed to do a consistency check for all of our music. I needed to set some metadata rules.
The first, most important rule, was no "Various Artists" tags ANYWHERE. There is no situation in which a "Various Artists" tag makes the most sense. If I'm looking for a soundtrack, "Various Artists" isn't going to help me. If I'm looking for a specific compilation, "Various Artists" isn't going to help me. So, I figured out the best way to handle "Various Artists" tags.
Video game soundtracks: tag the album artist as the company behind the game. For example, all of our Sonic soundtracks are tagged with "SEGA" as the album artist. All of our Persona soundtracks are tagged with "Atlus Sound Team" as the album artist. This way, it's easiest to find everything in those categories.
Compilations: tag the album artist as the record label behind the release. This always assures that similar compilations from the same companies are always grouped together. For example, if we want to just listen to a bunch of HARDCORE TANO*C music on shuffle, we don't have to go find an album - all of the HARDCORE TANO\C albums are under the same artist label. Same with things like the Exit Tunes Presents vocalsynth compilations, the Miku concerts and compilations from KARENT, etc. It means that like-sounding compilations will always be put together, which makes discovering new music in our library very* easy.
I have yet to find an edge case that doesn't work neatly under these two conditions.
The second rule was to consolidate artist tags as much as possible. As mentioned earlier, it makes organization a lot neater if I move featured artists to the song title instead of the artist field. This way, instead of having five different tags for the same band - i.e., "Anamanaguchi", "Anamanaguchi & Hatsune Miku", "Anamanaguchi & meesh", Anamanaguchi & HANA", "Anamanaguchi & 8485" - the featured artist is just in the title, so all of these songs would just be under "Anamanaguchi". However, this doesn't cover every case, so it needed to be decided on a case-by-case basis. For example, "Shelter" is a song by both Porter Robinson & Madeon. It is not "Shelter (feat. Madeon)" by Porter Robinson, so there are exceptions for more explicit collaborations. (A lot of music from Synthion, for example, we have exceptions for, since she often does collaborations with the same people often.)
These were the two biggest rules, and the ones that I would focus on. Just enforcing these two rules alone for our library proved to be a major hassle, and took about five hours of fixing tags for, but it was really worth it. Everything felt unified.
There was just one last thing to handle...
...foreign music.
It's no secret that we listen to a lot of Japanese music - I'm a huge Miku fan, after all - but the Japanese music in our library was very inconsistent - some of it was romanized, some of it was translated, some of it was still in Japanese. I decided that this inconsistency was going to really get on my nerves after a while, so when I was done fixing the artist tag situation, I got to work consolidating everything.
I had a bit of a hard time, at first, deciding the approach I wanted to take. I couldn't decide if I wanted to translate everything or romanize everything. I didn't really think leaving it in Japanese would really help us at all, because it would make remembering song names and searching for things kind of difficult. I didn't really want to do translations, either, since those can be kind of spotty - for example, is it "The Disappearance of Hatsune Miku" or "The End of Hatsune Miku"? Is it "Inferiority Superiority" or "Bring It On"?
I didn't want to be the authority of any of that, so I decided to simply romanize everything. I used two sources for romanized titles, primarily - VocaDB for most of the vocalsynth music in our library, and Apple Music for everything that VocaDB couldn't cover. This took several more hours, but at the end of it all, it really does make the whole library feel more complete.
I did take a few liberties, though - not everything is 100% compliant. For example, in some cases, I decided to actually translate song titles fully - the song "リモコン" by WONDERFUL★OPPORTUNITY! is technically romanized as "RemoCon", but I thought that sucked, and everyone knows it as "Remote Controller" anyway, so in our library, it's tagged as "Remote Controller".
At the end of the day, the compliance only really matters to me - it's our library, we answer to no one, and it's our metadata, we'll do whatever we want with it.
Finalizing Everything
Once I ran through the library for consistency one last time and decided all was OK, I only had one thing left to do - prepare the library for syncing to the iPod.
The first thing I did was run Bliss on the library folder one more time, so it could change the file names for any albums or songs that got shuffled around. Once the folder structure was all fixed up and compliant, I imported everything into Music.app, and there was our library - all consistent, all organized and properly tagged exactly the way I wanted it to be.
Honestly, it was beautiful.
So, with the library the way I wanted it, there was only one thing left to do.
I plugged the iPod into the Mac, and set it to sync the entire library to the iPod. I had it convert everything to 256kbps AAC when transferring it to the iPod, because it would be faster, take up less space, and still sounds pretty damn good. (Plus, it means our 170GB library only takes up ~45GB on the iPod's 256GB SD card, so we have plenty of room for future music.) I wait the few hours it takes to sync everything over, and then I grab the iPod and put on an album.
...and the album data for everything is corrupted.
You know how in old video games, when things would start glitching, all the sprites would get shifted around?
Yeah. Like that.
So I did a little bit more digging - and it turns out that this is a bug pretty much specific to Apple Silicon Macs. For whatever reason, the way syncing works on Apple Silicon Macs doesn't play nice with Windows-formatted iPods, and sure enough, the iPod was still Windows-formatted. So I restored it to Macintosh format, re-synced everything, and the issue was gone.
What a pain, but after that, I can say - the iPod works flawlessly!
It syncs, it plays all of our music. Album art works, playlists work, everything works really, really well. All off of an M1 Mac.
And, I have a workflow for adding new music pretty seamlessly. I have a "working" folder, where I can put any files that need to be converted, tagged, or organized. I can convert the files, fix the tags for consistency, and then run Bliss on that folder. Then, when that's all done, I can drag those new organized folders to the Music Collection. This prevents Bliss from messing with the pre-existing collection folder - once a folder is in there, it never gets touched again. Then, from the Music Collection, I can add the new files to Music.app, and then they sync to the iPod on the next sync.
It's made it really easy to keep everything organized and manageable. I'm really, really happy with the setup.
THE TL;DR SECTION
If you just want some tips & tricks from me on how to make managing your iPod easier, here they are.
- If you're trying to convert a FLAC library to work with iTunes, use XLD (free) or dbPoweramp (paid). dbPoweramp works better in my experience, but YMMV. Avoid using FFMPEG, it will cause playback issues. (fre:ac may also work.)
- If you're using an Apple Silicon Mac to sync your iPod, format it (restore it) on the Mac before syncing to avoid artwork issues.
- If you're using Rockbox, use this tool to make album artwork function.
CONCLUSION
Managing an iPod with modern software is a bit of a labor of love. ALAC isn't a very common format, and there's no simple way to make FLAC work flawlessly with the iPod. It can be tedious, and annoying, and kind of exhausting depending on how far you want to go with things, but the payoff is so worth it. The iPod is an absolutely amazing little device, and my personal favorite way to listen to an offline music collection. It may take a lot of work to get to a state that you're happy with, but if you treat it and your library right, it will reward you in kind with great sound, a seamless interface, and endless amounts of joy.
Thank you for reading this far in. This is the longest post ever put on this blog, and it was a lot of fun for me to write. Sorry if it's all over the place.
Once again, please let me know if you have any questions! If you use the social icons on the sidebar to contact us, address your message to Ichika, and I'll get back to you as soon as I can.
Thank you again for reading!
- Ichika, Lost Time System