I also "wrote" my own music player. It took less time to vibe code a player than it did to test 5-6 music apps and find out they were missing feature X that I wanted.
Same here. When I read this article a few hours ago, I realized that I should vibecode a player for myself. I often listen to multihour recordings of radio programs, and I have been wanting an app that would remember the files I've played and the playback position in each recording--that's all. I set Claude to it, and in half an hour it produced a native Mac app in Swift that worked perfectly on the first try.
I also wrote my own music player. In Lazarus, mplayer in slave mode. Wrote it 10+ years ago and never changed it since, using it daily: https://imgur.com/zyaFRYF
"...I wasn’t aware of other music players such as foobar2000 which my friend just pointed me to while writing this post..."
After reading this early sentence I stopped reading and wondered why that was. Not knowing the serious competition might be advantageous, it might be smart. When I've finished pondering why, I'll jump back in.
> I was surprised by my own ignorance and how much LLMs like to complicate stuff.
Exactly and it's like a plague. I think the main reason is that LLMs are generators, they like to generate code where code removal or reduction would solve the problem just as well. You ask them to fix something, they generate a fix. You tell them the fix didn't work, now they generate a fix for a fix, whereas a fix that would also reduce complexity existed from the start.
With a fair amount of babysitting and constantly reminding the agent that code removal is an option, you can eventually get a decent codebase but I wonder why this isn't a default. Because they are trained on mediocre code that is the vast majority of what's available on the internet? Most likely.
> the main reason is that LLMs are generators, they like to generate code where code removal or reduction would solve the problem
Don't over-index on this choice of words. LLMs can just as easily generate a diff that removes or refactors code, they don't have any intrinsic "preference" to always add more code, unless it's been trained into them.
A lot of the early training had concentrated on "wow factor" one-shot style demoable use cases, where the models indeed ended up with a tendency to assume they were in a "produce something new for me right now" situation and often or always started churning out additional code, even without all relevant information. As training regimes improve, and as customer demand evolves, this is changing, and the latest big models place a lot more emphasis on maintenance tasks - still not enough, but it's at least in the mix. As they mature, I'd expect the models' "instinct" to gradually align with what everyone's idea of a senior software engineer is, taking time to figure out if they can simplify and refactor rather than always adding more.
It's a new field, it will take time to get it right, but I don't doubt it will eventually be right.
> Because they are trained on mediocre code that is the vast majority of what's available on the internet
Again, this is outdated. It's true that the earliest training took this "spray and pray" approach, but data quality filtering is now a huge focus and the labs have made a lot of effort (and progress) in figuring out what good code is and getting the models to follow that. They've massively improved, in my experience, and it'll only get better. Again - give it time, this is new.
They have improved I agree but still, if left unattended they can produce a lot of unnecessary complexity. Even Fable and whatever the other top models.
Programming is engineering and it's hard. In fact outside of engineering the LLMs have become so impressively good at reasoning, pulling the necessary information, connecting the dots. And yet it's still not enough to produce high quality code.
Recent one was there was a text selection bug in Flutter that is fixed in the next minor version, but AI decided to create a hacky wrapper class that monitors all input gestures and manipulates them to avoid the bug with various timeouts and debounces. When it could have just updated Flutter.
It's been under my skin for a long time now, but every single free music player app I've used in the past 8 years plays my locally stored mp3s in the exact same order each time the shuffle button is on. Many others complain about that too.
I don't know if it's happening on Android OS level, but even VLC, plays songs in the exact same predictable order. I've left support notes on VLC's forums, and submitted the issue to issue cues and there are no responses each time.
None of that encourages me to pay for a premium app, shuffle has been around since CD changers.
I would rather have the same "random" order than what Spotify does; random never plays some songs, and overplays other. I get true random has the possibility of that, but when I've heard the same song for the 4th time in an hour, on a 20-hour playlist, something is wrong.
It sounds like maybe what you want is to have the "shuffle" mode play songs close to truly randomly while still penalizing songs that have been played too much recently. This gives us an optimization problem:
minimize KL(π || uniform) - β E_π[times played already],
where β is an inverse temperature determining how much you dislike repetition and π is your policy. Here I've arbitrarily chosen a reverse KL divergence because it leads to a nicer closed form:
π(song) ∝ exp(-β⋅"times song played already").
I wonder if anyone has implemented this before in a music playlist.
Easy version: Make a smart playlist whose criteria are 'last played is not in the last 3 weeks, last skipped is not in the last 3 weeks'. Randomize within that. Possibly add some other conditions like 'genre is not podcast'. I've been having iTunes/Music.app do this for... probably at least a decade, at this point, it doesn't track when you made playlists so this is just guessing.
My experience for years before finally dropping Spotify, and reinforced in some random comment online, was that it only grabs the first X songs in a playlist and shuffles among them, never proceeding to the rest. "First" may not be entirely correct but it was relatively consistent that a given playlist would always shuffle the same songs so it may have something to do with internal ordering/IDs.
I have this issue with youtube music only for some reason. For me "Shuffle" seems to be starting random, then after a handful of songs entering a loop of 6 or 7 songs. I never figured out why or looked it up, I just refresh the page. I know it must be only me somehow, but don't know what's happening.
>I have this issue with youtube music only for some reason…
Try navigating to the playlist and look below the currently playing track. There should be a "shuffle type" button bar showing 'Familiar', 'Discover', 'Chill', etc. It seems to produce better results for me if I explicitly choose familiar tracks or discover mode (or the other options, but i use the first two 99% of the time).
I think you can have a rss feed of your playlist, you could grep the urls, | rand them like you want and play with mpv or just download everything with yt-dlp.
The engineering of perceived randomness is an art.
The iPod comments don't fully apply to 'songs play in same order on shuffle', but still relevant if the players you tried actually have a smart shuffle that does things like matching metadata between consecutively played songs or some quickly computed properties like energy, and end up producing just a small set of plausible orderings that make a playlist listenable.
Auxio music player[1] for Android shuffles a new order each time the shuffle button is clicked (and ime is excellent for handling well-tagged libraries).
foobar2000 for Windows also changes the shuffle order but (at least in earlier versions) only after a relaunch.
My car's player (reading from a flash drive full of MP3s) doesn't have "shuffle", it has "random". The difference is subtle, but it means that each time it advances to a new track, it selects that at random. The result is that I never hear all the tracks in an album/playlist without hearing a bunch of repeats. Infuriating!
But when I play from my phone or PC, I use PlexAmp (backed by my Plex media server), which is the opposite extreme. Not only does it know what randomly shuffling is, but the server has analyzed the sonic profile of every track, and knows about similar artists and similar albums. So you can play an "artist radio" featuring that artist and other related stuff. And you can choose an auto DJ, which inserts between tracks the closest sonic match to the song it just played, or a brief detour of about 3 tracks that are spaced along the path from the track that just played to the one that's about to play. It's fantastic for discovering stuff you haven't heard in a long time within a very large library.
If you're on Android, I highly recommend trying the app Symphonium. It can connect to your Plex music library and the "Smart Flow" playlist bring all the auto DJ modes from Plex amp and add a few more options. It also looks far better imho.
Is what you call the "shuffle button" a "shuffle playlist" button or a "shuffle mode" button? There is a subtle difference between those two and for what I understand you want the second
To implement shuffle play, it is not necessary to actually shuffle filenames in memory. Just generate a random number modulo the number of files, and then play that file. That way your program can shuffle play any number of files, no worries about running out of memory.
By the way, the Roku box has a "media player" app in it by default, and it cannot shuffle play more than a handful of files. Completely useless.
BTW, Windows Media Player is the winner, as it "just works". Just point it at the root directory of the music files, turn on shuffle play, and it works, and doesn't crash.
That's random play, not shuffle play. Random play can repeat songs before all songs are played. Shuffle play will play all songs exactly once before any repeats occur. Random play "puts the card back into the deck" before dealing the next one.
You are correct, and that matters if it is a small number of music files. If it is a large number of files, the difference in user experience is irrelevant. But not needing to remember what was already played keeps the player memory footprint small.
Except "small" is very large because this runs face first into the birthday problem so the average distance between duplicates grows to the square root of the number of files.
Hell even actual shuffling is not necessarily enough to "feel" right for human psyche, famously despite the ipod doing actual shuffling[0] users complained because tracks of the same artist / album could still cluster over shuffling an entire library, so they implemented "smart shuffle" to skew the shuffle and break up clusters. An other option is to weight the random pick by how far back a track was last played, or how little it's been played overall. This has the advantage of favouring less played tracks across listening sessions.
[0] and frankly if the ipod was able to do actual shuffling back in 2005 the memory footprint is just a lazy excuse
I just looked at the code and it's apparently using the Fisher-Yates shuffle with a call to arc4random each pass. It's literally eight lines of Swift!
I've never suggested this before, but if the Android app store has truly been as bad as you claim for as long as you claim, you should seriously consider buying an Iphone to solve your problem.
In VLC I create a playlist myself, then save it as a file.
Then when playing that list the random function behaves as expected, by playing any random song after any other, including repeats and seeming omissions in no pattern whatsoever.
Disengage the random switch and it plays top-down.
Edit: This is in Windows, I haven't tried it in Android but have found the Android version to be less-capable in other ways.
> I’ve got no pre-rewrite history of the repo to check).
I love this type of story, because it describes a different Internet that I'm familiar with. And honestly it sounds pretty rough out there! But regardless, we all should be using some kind of version control (git), and as an added bonus you'd get your pre-rewrite history from it.
I mean they mentioned they had the code on codeberg initially, so it must have been in a git repo before. Maybe they just did the ol' `rm -rf .git && git init .`
Interesting Story. Starting my own hardware music player as a learning project[1] (that will probably take years until the first release) I noticed how MANY music player projects are out there (software and hardware ones).
This seems to be a field with so many different approaches and requirements, that no solution can fit them all and everyone settles with the least annoying one or starts their own.
Personally, I've found that since breaking up with macOS/iOS in 2020 my most missing feature is using my headphone remote to control volume or skip songs without taking my phone out of my pocket / touching my keyboard. It's still in my muscle memory, because I'm using my iPod Nano 7 to listen to audio books a lot and while every iPod and MacBook does support this, Linux capable notebooks don't.
Besides this single feature, for music I found navidrome with smart playlists[2] and Substreamer[3] / DSub[4] to be a great way to listen to local music, since Substreamer supports OFFLINE sync for playlists. So every time I get home I sync my smart playlists, which includes a "last played" filter / ordering - so I get to listen to "new" music every time.
Unfortunately the headphone remote stuff probably will never be fully fixed on Android, because google chose to block "longpress" on OS level for their own Voiceover, but like I said: The least annoying option.
For audio books I can recommend Audiobookshelf[5], which is self hosted and can be combined with the official Android app or some third party ones (Lissen, Storii and Voice from Paul Woitaschek). I'm probably sticking to my iPod until it dies completely - but lately I found the HiBy R1 to be Linux based and hackable[6], maybe I try to implement my own player / UI for it :-)
This post makes no sense. The author goes from having no internet due to a bombardment to LLM'ing. I find it hard to share the plight of a warzone when they go unhinged to build their own audio player afterwards (?!). If I want a music player every OS comes with one, and phones hold enough storage. USB thumb drives are also good. Failing that, burning CDs and using rechargeable batteries is another off-the-grid solution that will work fine, and CDs are easily transportable and will last for decades. Slightly physically damaged CDs are somewhat resilient and can be brought back to life with toothpaste, so they're somewhat "better" than files which shit the bed if there is any data corruption.
"The point is that the author wrote the music player app because they wanted specific features and for their own pleasure/coping."
But didn't look at popular alternatives, it seems, which is totally legit, go your own way 100% - but I felt the story, interesting as it is, was not being framed honestly from the start if I'm being honest, and that's a turn off.
I also "wrote" my own music player. It took less time to vibe code a player than it did to test 5-6 music apps and find out they were missing feature X that I wanted.
Shoutout to LIBLRC, a free API for lyrics search.
Same here. When I read this article a few hours ago, I realized that I should vibecode a player for myself. I often listen to multihour recordings of radio programs, and I have been wanting an app that would remember the files I've played and the playback position in each recording--that's all. I set Claude to it, and in half an hour it produced a native Mac app in Swift that worked perfectly on the first try.
I also wrote my own music player. In Lazarus, mplayer in slave mode. Wrote it 10+ years ago and never changed it since, using it daily: https://imgur.com/zyaFRYF
"...I wasn’t aware of other music players such as foobar2000 which my friend just pointed me to while writing this post..."
After reading this early sentence I stopped reading and wondered why that was. Not knowing the serious competition might be advantageous, it might be smart. When I've finished pondering why, I'll jump back in.
> I was surprised by my own ignorance and how much LLMs like to complicate stuff.
Exactly and it's like a plague. I think the main reason is that LLMs are generators, they like to generate code where code removal or reduction would solve the problem just as well. You ask them to fix something, they generate a fix. You tell them the fix didn't work, now they generate a fix for a fix, whereas a fix that would also reduce complexity existed from the start.
With a fair amount of babysitting and constantly reminding the agent that code removal is an option, you can eventually get a decent codebase but I wonder why this isn't a default. Because they are trained on mediocre code that is the vast majority of what's available on the internet? Most likely.
> the main reason is that LLMs are generators, they like to generate code where code removal or reduction would solve the problem
Don't over-index on this choice of words. LLMs can just as easily generate a diff that removes or refactors code, they don't have any intrinsic "preference" to always add more code, unless it's been trained into them.
A lot of the early training had concentrated on "wow factor" one-shot style demoable use cases, where the models indeed ended up with a tendency to assume they were in a "produce something new for me right now" situation and often or always started churning out additional code, even without all relevant information. As training regimes improve, and as customer demand evolves, this is changing, and the latest big models place a lot more emphasis on maintenance tasks - still not enough, but it's at least in the mix. As they mature, I'd expect the models' "instinct" to gradually align with what everyone's idea of a senior software engineer is, taking time to figure out if they can simplify and refactor rather than always adding more.
It's a new field, it will take time to get it right, but I don't doubt it will eventually be right.
> Because they are trained on mediocre code that is the vast majority of what's available on the internet
Again, this is outdated. It's true that the earliest training took this "spray and pray" approach, but data quality filtering is now a huge focus and the labs have made a lot of effort (and progress) in figuring out what good code is and getting the models to follow that. They've massively improved, in my experience, and it'll only get better. Again - give it time, this is new.
They have improved I agree but still, if left unattended they can produce a lot of unnecessary complexity. Even Fable and whatever the other top models.
Programming is engineering and it's hard. In fact outside of engineering the LLMs have become so impressively good at reasoning, pulling the necessary information, connecting the dots. And yet it's still not enough to produce high quality code.
Rewriting code often makes it more readable and robust. That is sometimes also true for the human -> llm direction.
Recent one was there was a text selection bug in Flutter that is fixed in the next minor version, but AI decided to create a hacky wrapper class that monitors all input gestures and manipulates them to avoid the bug with various timeouts and debounces. When it could have just updated Flutter.
Like human devs did not accumulate if blocks over if blocks, because they didn't understand the code, and fixed bugs at the completely wrong level.
At least that's my experience.
It's been under my skin for a long time now, but every single free music player app I've used in the past 8 years plays my locally stored mp3s in the exact same order each time the shuffle button is on. Many others complain about that too.
I don't know if it's happening on Android OS level, but even VLC, plays songs in the exact same predictable order. I've left support notes on VLC's forums, and submitted the issue to issue cues and there are no responses each time.
None of that encourages me to pay for a premium app, shuffle has been around since CD changers.
I would rather have the same "random" order than what Spotify does; random never plays some songs, and overplays other. I get true random has the possibility of that, but when I've heard the same song for the 4th time in an hour, on a 20-hour playlist, something is wrong.
It sounds like maybe what you want is to have the "shuffle" mode play songs close to truly randomly while still penalizing songs that have been played too much recently. This gives us an optimization problem:
where β is an inverse temperature determining how much you dislike repetition and π is your policy. Here I've arbitrarily chosen a reverse KL divergence because it leads to a nicer closed form: I wonder if anyone has implemented this before in a music playlist.Easy version: Make a smart playlist whose criteria are 'last played is not in the last 3 weeks, last skipped is not in the last 3 weeks'. Randomize within that. Possibly add some other conditions like 'genre is not podcast'. I've been having iTunes/Music.app do this for... probably at least a decade, at this point, it doesn't track when you made playlists so this is just guessing.
uhm this is exponential backoff
Spotify is an organization. Of course they have an active interest in what things you stream and which ones you don't.
IIRC in Germany they don't want you to stream whole albums, as under GEMA rules an album "performance" costs more than individual songs.
My experience for years before finally dropping Spotify, and reinforced in some random comment online, was that it only grabs the first X songs in a playlist and shuffles among them, never proceeding to the rest. "First" may not be entirely correct but it was relatively consistent that a given playlist would always shuffle the same songs so it may have something to do with internal ordering/IDs.
I have this issue with youtube music only for some reason. For me "Shuffle" seems to be starting random, then after a handful of songs entering a loop of 6 or 7 songs. I never figured out why or looked it up, I just refresh the page. I know it must be only me somehow, but don't know what's happening.
>I have this issue with youtube music only for some reason…
Try navigating to the playlist and look below the currently playing track. There should be a "shuffle type" button bar showing 'Familiar', 'Discover', 'Chill', etc. It seems to produce better results for me if I explicitly choose familiar tracks or discover mode (or the other options, but i use the first two 99% of the time).
I think you can have a rss feed of your playlist, you could grep the urls, | rand them like you want and play with mpv or just download everything with yt-dlp.
Mandatory iPod Shuffle plug: https://sjdm.org/pipermail/jdm-society/2006-October/002793.h...
The engineering of perceived randomness is an art.
The iPod comments don't fully apply to 'songs play in same order on shuffle', but still relevant if the players you tried actually have a smart shuffle that does things like matching metadata between consecutively played songs or some quickly computed properties like energy, and end up producing just a small set of plausible orderings that make a playlist listenable.
Auxio music player[1] for Android shuffles a new order each time the shuffle button is clicked (and ime is excellent for handling well-tagged libraries).
foobar2000 for Windows also changes the shuffle order but (at least in earlier versions) only after a relaunch.
[1] https://github.com/OxygenCobalt/Auxio
Huh, I'm using Musicolet, never really experienced it. What's the number of mp3s you have locally? Maybe that is playing a part in the predictability?
My car's player (reading from a flash drive full of MP3s) doesn't have "shuffle", it has "random". The difference is subtle, but it means that each time it advances to a new track, it selects that at random. The result is that I never hear all the tracks in an album/playlist without hearing a bunch of repeats. Infuriating!
But when I play from my phone or PC, I use PlexAmp (backed by my Plex media server), which is the opposite extreme. Not only does it know what randomly shuffling is, but the server has analyzed the sonic profile of every track, and knows about similar artists and similar albums. So you can play an "artist radio" featuring that artist and other related stuff. And you can choose an auto DJ, which inserts between tracks the closest sonic match to the song it just played, or a brief detour of about 3 tracks that are spaced along the path from the track that just played to the one that's about to play. It's fantastic for discovering stuff you haven't heard in a long time within a very large library.
If you're on Android, I highly recommend trying the app Symphonium. It can connect to your Plex music library and the "Smart Flow" playlist bring all the auto DJ modes from Plex amp and add a few more options. It also looks far better imho.
Is what you call the "shuffle button" a "shuffle playlist" button or a "shuffle mode" button? There is a subtle difference between those two and for what I understand you want the second
Most people want the second - if they hit it, it picks a random song, and then plays all of the remaining songs randomly before repeating.
Few people want to shuffle the playlist (which is closer to above) or worse, to actually randomly select a song each time.
Pretty much every USB music player has the same faults:
1. shuffle play does not work
2. crashes if there are more than N songs
3. does not find songs in subdirectories
All of these are trivial to fix. I do not understand the programmers who make the firmware.
wow hacker news wins again. i am going to fix these in my music player. i think 2 & 3 are chill already... and i can totally fix 1. thanks!
To implement shuffle play, it is not necessary to actually shuffle filenames in memory. Just generate a random number modulo the number of files, and then play that file. That way your program can shuffle play any number of files, no worries about running out of memory.
By the way, the Roku box has a "media player" app in it by default, and it cannot shuffle play more than a handful of files. Completely useless.
> Just generate a random number modulo the number of files, and then play that file
That won't be uniform. If you want really random shuffle, mod to the closest next power of 2 then re-sample until you get a number within the bounds.
BTW, Windows Media Player is the winner, as it "just works". Just point it at the root directory of the music files, turn on shuffle play, and it works, and doesn't crash.
That's random play, not shuffle play. Random play can repeat songs before all songs are played. Shuffle play will play all songs exactly once before any repeats occur. Random play "puts the card back into the deck" before dealing the next one.
You are correct, and that matters if it is a small number of music files. If it is a large number of files, the difference in user experience is irrelevant. But not needing to remember what was already played keeps the player memory footprint small.
Except "small" is very large because this runs face first into the birthday problem so the average distance between duplicates grows to the square root of the number of files.
Hell even actual shuffling is not necessarily enough to "feel" right for human psyche, famously despite the ipod doing actual shuffling[0] users complained because tracks of the same artist / album could still cluster over shuffling an entire library, so they implemented "smart shuffle" to skew the shuffle and break up clusters. An other option is to weight the random pick by how far back a track was last played, or how little it's been played overall. This has the advantage of favouring less played tracks across listening sessions.
[0] and frankly if the ipod was able to do actual shuffling back in 2005 the memory footprint is just a lazy excuse
Amperfy for the Iphone randomizes the shuffle.
I just looked at the code and it's apparently using the Fisher-Yates shuffle with a call to arc4random each pass. It's literally eight lines of Swift!
I've never suggested this before, but if the Android app store has truly been as bad as you claim for as long as you claim, you should seriously consider buying an Iphone to solve your problem.
In VLC I create a playlist myself, then save it as a file.
Then when playing that list the random function behaves as expected, by playing any random song after any other, including repeats and seeming omissions in no pattern whatsoever.
Disengage the random switch and it plays top-down.
Edit: This is in Windows, I haven't tried it in Android but have found the Android version to be less-capable in other ways.
"AMP" is unfortunately close to "AIMP", another music player. (https://aimp.ru/)
There's a lot of music players for Android: https://fmhy.net/mobile#android-audio-players.
And that's a curated list!
And Winamp.
And zinf, formerly freeamp, but don't call it free*mp, or winamp will sue, was always the motto.
> I’ve got no pre-rewrite history of the repo to check).
I love this type of story, because it describes a different Internet that I'm familiar with. And honestly it sounds pretty rough out there! But regardless, we all should be using some kind of version control (git), and as an added bonus you'd get your pre-rewrite history from it.
I mean they mentioned they had the code on codeberg initially, so it must have been in a git repo before. Maybe they just did the ol' `rm -rf .git && git init .`
Musicolet for android has a shuffle, and also folder view, that works very well. Truly shuffled up.
I agree, I've been using it for 5 years now, no qualms, it just does its job, and its job well. Someday I'll grab premium to support the dev...
Interesting Story. Starting my own hardware music player as a learning project[1] (that will probably take years until the first release) I noticed how MANY music player projects are out there (software and hardware ones).
This seems to be a field with so many different approaches and requirements, that no solution can fit them all and everyone settles with the least annoying one or starts their own.
Personally, I've found that since breaking up with macOS/iOS in 2020 my most missing feature is using my headphone remote to control volume or skip songs without taking my phone out of my pocket / touching my keyboard. It's still in my muscle memory, because I'm using my iPod Nano 7 to listen to audio books a lot and while every iPod and MacBook does support this, Linux capable notebooks don't.
Besides this single feature, for music I found navidrome with smart playlists[2] and Substreamer[3] / DSub[4] to be a great way to listen to local music, since Substreamer supports OFFLINE sync for playlists. So every time I get home I sync my smart playlists, which includes a "last played" filter / ordering - so I get to listen to "new" music every time.
Unfortunately the headphone remote stuff probably will never be fully fixed on Android, because google chose to block "longpress" on OS level for their own Voiceover, but like I said: The least annoying option.
For audio books I can recommend Audiobookshelf[5], which is self hosted and can be combined with the official Android app or some third party ones (Lissen, Storii and Voice from Paul Woitaschek). I'm probably sticking to my iPod until it dies completely - but lately I found the HiBy R1 to be Linux based and hackable[6], maybe I try to implement my own player / UI for it :-)
1: https://github.com/nanowave-player/nanowave-ui
2: https://www.navidrome.org/docs/usage/features/smart-playlist...
3: https://substreamer.org/
4: https://f-droid.org/de/packages/github.daneren2005.dsub/
5: https://github.com/advplyr/audiobookshelf
6: https://github.com/Jepl4r/sonix-player
Looks fine an dandy, but the name is too similar to AIMP... another player.
This post makes no sense. The author goes from having no internet due to a bombardment to LLM'ing. I find it hard to share the plight of a warzone when they go unhinged to build their own audio player afterwards (?!). If I want a music player every OS comes with one, and phones hold enough storage. USB thumb drives are also good. Failing that, burning CDs and using rechargeable batteries is another off-the-grid solution that will work fine, and CDs are easily transportable and will last for decades. Slightly physically damaged CDs are somewhat resilient and can be brought back to life with toothpaste, so they're somewhat "better" than files which shit the bed if there is any data corruption.
The point is that the author wrote the music player app because they wanted specific features and for their own pleasure/coping.
"The point is that the author wrote the music player app because they wanted specific features and for their own pleasure/coping."
But didn't look at popular alternatives, it seems, which is totally legit, go your own way 100% - but I felt the story, interesting as it is, was not being framed honestly from the start if I'm being honest, and that's a turn off.