This is a good read, admittedly haven't finished it yet. I like reading about the more granular details developers decide on and why.
I will say that I sympathize with the idea that ... I don't like any audio players that I've tried, but in the world of music apps the layout of screens and UI seem almost universal across them and ... I just don't like them / don't "get it".
I feel like I'm boxing with every music app ever...
I appreciate anyone who takes a shot at making something new.
I'd still love to get a proper successor to the Sandisk Sansa Fuze, just with USB-C charging instead of its proprietary charging cable.
There's plenty of "luxury" /audiophile MP3 players out there which cost in the hundreds of dollars, but that one was in the sweet spot of bang-for-your-buck music player that I could just use for listening to music on long plane rides etc. without draining my smartphone battery.
I had been wanting something similar recently and ended up buying a Hifi Walker H2 and loading rockbox on it. Works great, and it’s a total nostalgia trip to be using rockbox again after so many years!
Wheels will always be the best way to navigate music libraries.
Oh, nice! That undercuts the price of the FiiO JM21 by about half, which was the other entry-level audiophile music player I was looking at if I ever decided to splurge on one:
You have many options for DAP, unfortunately they are often android based. In some rare cases, they are either pure custom OS, or stripped down android device. I have a Cayin N3U, I hesitated a lot with some Hobby device as it's a small brick and Android, while the android interface is still too present for my taste, and a bit too large, I have no regret, I really wanted something dedicated, no Bluetooth, tube, portable, no streaming, no extra app.
I get what you're thinking of with having a separate device, but I've found it better to just have a decent extra battery pack to travel with. You get a lot more flexibility with use. Maybe you just wanted to listen to music. Maybe you later decided you actually wanted to read instead, or play a game, or watch a video. Maybe you forgot to sync those podcasts until you got to the airport waiting on the plane and only just downloaded it and now it's a hassle to bust out a cable and sync it to your offline only MP3 player.
Essentially, you could carry a small battery attached to an extra sigle-task dedicated device, or a slightly larger battery in about the same-ish form factor that will let you use that energy to do anything you want with your other device you're probably already carrying.
If your phone is in whatever airplane mode, battery saver mode, etc. it's not going to use that much power just to play local music.
It's interesting that most/all of the available tools for playing digital music, a well-known and very popular activity... suck. Do we think that's enshittification or product managers misunderstanding the market? In a normal universe one might otherwise expect it to be saturated with options.
The enshitification was completed when they convinced us to no longer want to own our own copies of music but to perpetually rent access to their content.
The latest Iteration I discovered 2 days ago, a audio service(via Amazon), where you have limited time for listening. So I get to listen to that new audiobook, but see my 10 h contingent decrease every second I listen.
Creates a new vibe for me.
Libraries had the same count down, but it just wasn't in your face. If you returned a book after the agreed time, they charged you late fees. These guys just cut off access to it. They should have a late fee equivalent where you can extend the time without having to pay the full rental rate again.
Maybe I was not clear, but the counter only ran while it was playing.
That is something completely different to me, as it limits replaying.
Having access for 14 days lile a boo kwould be something very different and more OK with me. But limiting the act of playing that audio itself has a new quality for me.
Yes, but recording the audio is annoying, but currently what I will do ...
(DRM of course)
Edit: but apparently I was wrong and the "countdown" was just the time left of the audiobook. But the mobile UI was stuttering, so that wasn't clear. But thinking about it, I am surprised it ain't implemented yet for real.
I think you could actually just play the audiobook and screen capture video the whole time and you'd have a decent clear video with audio you could just rip the audio from. Only problem is you would have to have it running the whole amount of time without any hiccup in that process but I got a great, rare piece of audio I couldnt find anywhere that way
People have spent many decades without actually caring to own their music content. Back then they used these things called "radios" to enjoy music content without owning the collection. Streaming services today are just another evolution of listening to the radio.
Not everyone had some massive record collection and hundreds of cassette tapes.
I never have liked commercial radio. There's too little music, and too many commercials. Then of course there's the whole payola issues, and the lack of variety in the tracks played on the radio. In major markets or college towns, there might be a few stations that just play good music based on what the program director or specific jockeys want to play. Luckily, I had one near me, and it offered me a catalog of music I just wasn't going to get otherwise. So for me, the only way to hear what I considered "good" music was to collect it. I spent lunch money and other random bits of cash I'd receive as a teen solely on music.
Today, those "cool" stations have primarily been slurped up into iHateRadio / Comcast conglomerates, so commercial radio is useless. The internet is the only saving grace for kids today, but even streaming platforms don't do it for me. Sadly, youtube is about the best thing for its ubiquitous availability. Bandcamp/Soundcloud are cool, but still not the same discoverability as YT.
Even with my collection, it's still not instantly accessible as I'd like due to the manual labor of digitizing. I've tried on multiple occasions, but it's only a fraction of the collection. It's just too easy to find it with yt-dl
I mean sure, there's always been a lot of people who didn't care for the radio and absolutely found it valuable to buy physical media copies or later digital versions they truly owned. But there's pretty much always been a large chunk of people who didn't care to own a lot of content. They didn't have to be "convinced" to no longer want to own their own copies of music, they never cared to from the start. They just didn't really have any other options other than maybe buy a small handful of physical media or listen to the radio. Now they have a ton more options. It's not enshittification to build new services to target customers which previously only had worse options. Before, these users practically only had AM/FM radio to service what they were looking for. Now there's lots of apps out there with ad supported or cheap tiers (the price of a few CDs a year to get access to thousands and lots of constant new content) offering them on-demand music and autoplaylists and what not.
These platforms aren't necessarily drawing people who really wanted a big privately curated music collection to own forever, they're drawing the people who just want to listen to music and not have to spend much or anything at all for it. Which happens to be a ton of people.
Yeah I think a sibling has it right: DRM factors into this, and TPTB do not want another Winamp or VLC that gives freedom to users to play what we want.
The situation for me on Android would be hilarious if it weren't so saddening. Since I purchased a KitKat tablet in 2015, I've more or less stuck to the "Android Files" app to play music files. Yes, that has been the best solution: no app install required, bare bones, no feature demands from me. In fact, rather than making playlists, I would just copy out tracks to a new folder and play them in there. Want to repeat one? Make five copies of it!
On Chromebook I'm using the builtin app, Gallery. It's utterly barebones as well. All I want to do is listen to a track.
This has continued even to the present day, but you know what? Our days are numbered, because apps are staking out moats in terms of file types they will handle. They're looking to reduce generic handling of multiple file types.
I've been trying to conform to this "new normal" by using YouTube Music. With my Premium subscriptions I should be able to download any streamable track, and also listen to files on-device. This is working out poorly. The on-device management is abysmal and makes you want to die. The downloading feature just sort of... fills up my storage, and I don't really even use it. I still fall back on Android Files because Music is such a horrible app, except when I'm using it to stream.
Software for playing audio used to be great even with far fewer engineering resources going into them. That suggests the reason they are getting worse is deliberate and stems from a misalignment between what software users want and what the producers want.
Most music software companies today are two businesses joined together:
1. A software company that makes apps to let people listen to music.
2. A content licensing company that pays artists and record labels to give them access to music and let people listen to it.
If they were only #1 then they would be agnostic to what music people listen to and how much of it. WinAmp didn't give a damn how big your music library was, what songs you listened to, or how often, because that was entirely between you and your MP3 collection.
But, say, Spotify has to pay someone every time you listen to a song and how much they pay depends on what you listen to and how often. That gives them a direct, perverse incentive to build an app that routes you away from expensive audio you might prefer towards cheap stuff that eats up your time but doesn't cost Spotify as much.
That's why every single time I open the fucking Spotify app I see a wall of podcasts even though I have literally never listened to one and never will. They don't put them there for my benefit, but for theirs.
For Spotify, the end game is routing people towards eventually-AI-generated musak that they themselves own the licenses for because it's free for them. This is directly analogous to why Netflix is now constantly pimping their own often-shitty produced shows over movies you might actually prefer.
The reason we aren't saturated with options is that producing a media app without also having deals that give the app direct access to media to play dumps a lot of work back onto users and most users these days simply don't have a local media library or want to maintain one.
And spinning up a new app that does off content directly has huge startup costs. You need an army of lawyers to go out and negotiate deals with every record label out there, and those labels probably hate you out the gate since they are still salty about not making anywhere near as much money as they used to make when they sold CDs.
Spotify (and other streaming services) has a stronger incentive to push things you're actually likely to listen to and find value in, otherwise you're likely to not use the app and stop paying them.
And it's funny you point to the podcasts as an example for that, a lot of the podcasts and now audiobooks they push are some of the most expensive content they have.
The game every big media company is playing now, and the thing that Doctorow coined as "enshittification" works sort of like this:
1. Companies want you to keep paying for the subscription, so they want to offer you things with value.
2. At the same time, since you're paying a flat fee, they don't get much incremental reward for offering you things of incrementally greater value. So their incentive is to cut costs by offering you as little value as possible as long as the value is juuuuust above the threshold where you (well, the aggregate behavior of all users as "you") cancel.
3. Because of lock-in effects like having a huge library of liked songs and playlists in Spotify, being in the middle of binging an exclusive show on Netflix, the threshold of frustration where you would cancel gets higher and higher.
4. Thus, they are incentivized to increase lock-in because it enables them to cut more costs and deliver less value.
VLC has always been more than sufficient for me, or mp3blaster back in the day for a TUI app. I have trouble understanding why those or similar solutions are not sufficient for others....just interface preferences I guess?
I think it's a combination of both scale and people's expectations.
As the size of your music library goes up, the UX changes. The original iPod UX was (at least for me) genuinely awesome. It became less awesome as iPods got 40, 60, and larger storage, and it was pretty much unusable when I modded one to have 1TB of storage.
And related but different, everybody's expectation of what "a large music collection" is varies wildly.
I don't necessarily think this is intentional enshittification, I lean more towards "there's no right solution for everybody, and there's probably not even a dozen different right solutions that encompass most people".
It's hard to answer that question without understanding what specifically "sucks" in all the tools? I mean, the market is saturated with options, there are dozens of apps and streaming services well suited for "popular". It's the more advanced parts that are underserved, but that's just what you'd expect in any normal universe, you're rarely popularly saturated with greatness.
Most of the market of actual paying customers don't really care to have directories of FLAC files and terabytes of local data. And most of the people who have large collections of FLAC files probably didn't spend much to get those collections and aren't likely to bother paying for an app to be developed and supported. Most people I know with a local music library of thousands of FLACs spent $0 on that content.
And then there's a massive chunk of the market that finds the tradeoff of ads for "free" access to music an acceptable tradeoff. A few dollars a month in cost for access to music is way more than they're interested in spending, even $10 for a CD is more than they're usually looking to spend to acquire content. They're the kind of people who maybe only bought a handful of CDs or cassette tapes back int the day total and got a lot of their content from the radio.
Most of the paying customers for digital music tend to be generally OK or even prefer streaming services. And generally speaking, those streaming apps work pretty OK. Most work better than the early streaming/subscription apps back in the day (like old Rhapsody and Zune Music and non-pirating Napster). I still remember how long it would take to go from clicking Play on Zune to the time it would actually start playing the song compared to Spotify which felt nearly instant in comparison. Not having to reconnect my Creative Zen every few weeks refresh the DRM from Napster. Having all that content on demand from my wireless portable device. Practically all of what is available today is quite a bit better than what was, in terms of "I don't want to bother buying all of this content, I'm OK with renting a lot of it" standpoint.
I've got a collection of music I own, things I really care about. Mostly physical formats, a few hundred songs exclusively digital files. But for a lot of music I consume, I don't really care if I have it locally or have it forever. Its like listening to the radio, that song may never play again, that's OK. Buying all that content legitimately costs considerably more than what I pay for a streaming service, so the streaming service makes a ton of economic sense for what I'm looking for. I'm mostly looking for something in between a radio and a privately curated music collection, which is exactly what streaming is.
They specifically ditched react-native because of their requirements regarding file system traversal, so this is definitely not something that could have been done in-browser.
But unfortunately not on Safari respectively the iOS webview, which would have been mandatory for the author to use.
If I am wrong, I‘d gladly take a solution. I think this is one of the main problems for PWAs: No good , platform-independent way to access the local file system. As in „pick once, access forever“.
Sure, I did it 13 years ago and still use it daily. On a PC though, mostly. (But the actual player was mobile first, as it was my remote connection to the PC that is connected to the bass box. But works also standalone.)
I just never polished it to publish it, but it is quite easy and I guess ChatGPT can help with the basics as no arcane knowledge is required. (Except maybe the playing while screen is off.)
You also need a small node script, though or something different with system access to scan the media files. I think in browser tools make this now somewhat possible without(beware of security restrictions), but my approach is simply a node script scanning the music folder and generating a list that the media player consumes to find files for the player. I still didn't got around to make it automatic, but I don't add so much music (anymore).
I guess I will give it a try to see, how good it works a mobile player nowdays. I always wanted to upgrade it, so I can connect to spotify from my player as I hate the spotify mobile app.
It's actually surprisingly hard to get iOS Safari to keep playing audio with the screen off.
When I made https://ambiph.one I ended up having to route everything through a MediaStreamAudioDestinationNode to trick Safari into thinking it's a livestream, which is apparently the only type of audio allowed to play in the background
Hey Matt! I've been a fan of Ambiphone for a while and I see your comments on HN surprisingly often. I've been trying to build a different web audio player with inspiration taken from yours. I haven't figured out the screen off audio thing, so thank you so much for sharing this demo!!!
Thanks so much, that's really cool to hear! Let me know if you ever hit any more problems, I've been meaning to blog about a bunch of problems I had to work round in various browsers but haven't got round to it yet, so happy to answer any questions
The solution I found after approximately two months of struggling with this problem: you have to generate an audio file that is a few seconds of silence, play it on a loop, and play it at the same time as the actual audio file you want to play (via separate audio elements, or an AudioContext). Specifically I believe you need to make sure the silence is “playing” at track boundaries for the real audio, so there is never a single moment where your webapp stops playing audio.
I have been able to have multiple streams on iOS, but not easily. GarageBand might be able to do this via imports, but I’m not sure it it lets you queue/play multiple samples simultaneously like it will on macOS iirc.
If you are playing music through Spotify in the background, foreground audio in Snapchat still plays normally while recording and playing back just recorded snaps, as well as snaps or memories you have prepared earlier. Sometimes you need to start playback on Spotify again via Control Center, because Snapchat steals focus or takes priority for audio output or something, but it is just part of the jankyness of this workflow, which is probably not intentionally designed to be used the way I use it. If you combine these quirks with Screen Recording, you can make simple audio loops by recording simultaneously via Snapchat and iOS Screen Recording, then use those videos as uploads to Snapchat to stack the loops over each over by selectively queuing them, with audio from a video in Snapchat playing at the same time as audio from Spotify.
It’s kind of a weird workflow, but it’s neat that it works. It feels intentional, as most apps stop background audio playback when starting recording on the same device, but at least Snapchat does not do this, so it’s at least technically possible.
Ohhh that's interesting, so the root cause for my workaround working might be that the "live" audio node that I stream everything else to effectively never stops
I won't comment on the merits of this project, but I put my entire media collection, including all audio, in Jellyfin, and I find Finamp (available for Android and iPhone) to be convenient player, especially that it has easy download of entire albums, artists, etc. and "offline mode" you can toggle on so you can random-play whatever you've downloaded, even in places with no phone reception.
It is available, but the last time I tried it, I was only able to select specific audio files for import. I couldn't import the whole directory at once
Wireless charging means I rarely (perhaps even never for my current phone) plug it in with a cable. It wouldn't be a huge deal if I needed to to sync music, but it's certainly friction to my adopting apps that require that.
Managing local music with Music.app and syncing with Finder iPhone sync still works good for me, but Music.app does seem unmaintained for a couple years now with some annoying bugs since the terrible Big Sur rewrite. Despite the flaws this combination is still the best music library management + mobile sync solution I've seen (plz recommend!), but I feel eventually will have to write a system myself since the software is not maintained and not cross platform.
Part of the issue with the Music “rewrite” is that it’s less of an actual rewrite and more of a copypaste from iTunes. Lots of iTunes quirks remain, like the modal settings/preferences window that’s a holdover from the OS 9 days (OS X settings windows aren’t supposed to be modals).
My hunch is that they’ve got an actual from-scratch rewrite in the works that’s similar to the all-new WinUI-based Windows version of Music that came out a while back.
The built in Finder sync is still very broken on my 5th Gen Video iPod. The most annoying breakage was trying to sync podcasts - it worked fine back when iTunes was the program to do that with, but when using the Finder sync on Big Sur it's buggy and does not remember your place in the podcast if you move to another track / podcast and back, which functionally makes podcasts longer than a few minutes unusable on the device.
It’s amazing to me that iPod syncing still works. I use a 2ᴺᴰ gen nano and my son uses a, 6ᵀᴴ gen. I preferred managing in iTunes to finder, but it’s crazy that a 20 year old player with a proprietary software interface still works.
Apple is so quick to drop support for some things and keep other things around seemingly indefinitely.
For music on iOS I can't recommend foobar2000 [1] enough - and I tested ALL of the alternatives. You can import ANY folder (probably what OP is looking for) or use your "iPod Library". [2]
Personally, I sync my music via Synctrain (a Syncthing client). [3]
I was unaware that synctrain existed! That solved my last issue I had with my iPhone. I have been using keepass on various platforms to sync my password list, and with keepassium + synctrain I have my iPhone covered. Thank you!
I was unaware foobar2000 existed on iOS too, but the Windows version is my favorite audio player on that platform too.
>Even after the DMA Act in the EU, sideloading still isn’t fully open. EU users can now install apps from third-party marketplaces directly from a developer’s site, but only if that developer still enrolled in Apple’s $99/year program and agrees to Apple’s Alternative Terms. For personal/hobbyist use, this still doesn’t remove the 7-day dev build limitation.
Does Apple want to face a formal non-compliance judgment under the DMA, or is there another reason for Apple's blatant contempt of court with its refusal to properly and fully implement the mandated sideloading[1]?
[1] The Digital Markets Act (DMA) does mandate sideloading in Article 6(paragraph 4). It requires designated gatekeepers, which includes Apple for its iOS operating system, to allow for the installation and use of third-party apps and app stores. ( https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng )
I built my own web app to listen to full albums while allowing me to take breaks and switch devices. I really like to listen to albums from front to back but I found that at least YouTube Music doesn't remember playback position and you can't just switch devices without pulling up the album again on the other device and finding the position where you left off. My web app lets me paste a URL that is then downloaded to the server using yt-dlp and can be streamed from there. It always remembers playback position so I can listen from the phone in my car and then continue on the laptop at work from where I left off. It also works great for adding mixes from other sources such as NTS Radio - one of my favorites.
I personally use the Documents app by Readdle. I have the free version and have been using it to transfer and play audio files for like 3 years. Their audio player looks just like a music player and has all controls too.
You can transfer files to the app over wifi or even use files from the Files app.
On iOS I'm using Evermusic player, which allows syncing with different online sources. First I used it with my Dropbox folder, then moved to my self-hosted WebDAV.
Nice write-up - although I thought you've built your own HARDWARE audio player first.
However, I feel like this is one of the most re-invented wheels I've come across so far. Nobody seems to be happy, everybody seems to fail to build something that fits at least 80% of the requirements most people have.
My personal K.O. criteria is a bit awkward in days of bluetooth and wireless devices: Working cable headphone remote controls like Apple devices had for more than 10 years now - especially useful for audio books.
Years ago I tried to write a cross platform audio player[1] app with C# and Flutter inspired by iPod Nano 7g, but it always failed for the same reason: I could not get the headset controls working properly.
I've also spent some days to submit a PR on audiobookshelf-app[2], but it didn't get merged, although it worked pretty good on my device.
Nowadays I use a combination of my old iPod Nano 7g for music and audiobooks on the go and my Android GrapheneOS Phone as spare device for "streaming" something I don't have with me using Navidrome[3] and Substreamer[4] / DSub[5] for music and audiobookshelf-app[6] and VLC Media Player[7] for audiobooks (the offline support for audiobookshelf regularly breaks on my device) - most of these are available on fdroid or even official app stores.
Btw, if you ever wondered, why Apple EarPods do not support Volume Control on Android devices and vice versa, see this link[8] - it's definitely worth a read
Interesting read, nice to see technical details and rationale for building it this way. I made a similar one (https://www.catnapgames.com/tiny-player/) except instead of iCloud I rely on web based uploads.
For me one of the high level takeaways was to use ffmpeg next time. Apple APIs for decoding are nice but have limited support for file formats. And then there’s the lockin aspect..
It's a web app with the Spotify Web Playback SDK or a good old MP3 HTTP server and API like Internet Archive.
It works crazy well on a ChromeBook, and reasonably well on an iPhone, iPad or Android both through a native app with a webview component or the browser.
I have a theory the pendulum is swinging back and there is a demand for controlling our own music and music interface, and web technology is sufficiently good for implementing players.
Years and years ago I tried to store and organize family photos using iTunes on my computer. Suddenly, I could not use image files directly any more , for example edit them in Photoshop, without having to jump through hoops. That was when I ruled out apple products for ever.
..
It's enshittification.
> Initially, I avoided Swift because of my previous experience with it […] without native async/await at that time, writing concurrent code compared to Go or JS/TS felt clunky and boilerplate-heavy.
I have to disagree. Async may makes concurrent code easier to write, but also less simple to reason about as it grows. In a complex async codebase, I find it harder to reason about code flow and concurrency.
If the goal is to reduce the cost of executing threaded code, we have a solution in green light weight threads.
If we aim to reduce the cost of maintaining threaded code, I expect async to end up costing more effort in the long run.
> Async may makes concurrent code easier to write, but also less simple to reason about as it grows. In a complex async codebase, I find it harder to reason about code flow and concurrency.
Good concurrency should make the code simpler to understand and reason about as it grows. Simply having process/service based encapsulation is a huge win. IMO this is a failing of the async/await abstraction, not concurrency itself.
> Good concurrency should make the code simpler to understand and reason about as it grows.
As an ideal.
But you can only go so simple once you have a piece of data that is read at the same time by many, while also maybe mutated by at least one. And as simple you can get version 1.0, as software grow, it gets new features which necessitate more interactions with that data, which makes synchronization more complex.
> [..] once you have a piece of data that is read at the same time by many, while also maybe mutated by at least one.[..]
Dataflow patterns avoid this sort of issue by eliminating shared memory mutation. All data flows through the system by value with mutations only flowing downstream. There are several "Concurrency Patterns" videos by Rob about using these patterns in Go on youtube.
208 comments
[ 2.8 ms ] story [ 192 ms ] threadI will say that I sympathize with the idea that ... I don't like any audio players that I've tried, but in the world of music apps the layout of screens and UI seem almost universal across them and ... I just don't like them / don't "get it".
I feel like I'm boxing with every music app ever...
I appreciate anyone who takes a shot at making something new.
I'd still love to get a proper successor to the Sandisk Sansa Fuze, just with USB-C charging instead of its proprietary charging cable.
There's plenty of "luxury" /audiophile MP3 players out there which cost in the hundreds of dollars, but that one was in the sweet spot of bang-for-your-buck music player that I could just use for listening to music on long plane rides etc. without draining my smartphone battery.
Wheels will always be the best way to navigate music libraries.
https://www.amazon.com/JadeAudio-JM21-Snapdragon-Bluetooth-P...
You can replace the hard drive with MicroSD/SD or compact flash cards.
https://www.iflash.xyz
You can buy different color faceplates/backplates, upgrade the batteries, etc.
https://www.idemigods.com/iPod_5th_5_5_Generation_Video_Part...
[0] https://gerrit.rockbox.org/r/c/rockbox/+/6510 [1] https://github.com/amachronic/echoplayer
I don't even need it to be portable. In fact, I'm happy with a "component stereo" look with a VFD display. ;-)
Essentially, you could carry a small battery attached to an extra sigle-task dedicated device, or a slightly larger battery in about the same-ish form factor that will let you use that energy to do anything you want with your other device you're probably already carrying.
If your phone is in whatever airplane mode, battery saver mode, etc. it's not going to use that much power just to play local music.
That is something completely different to me, as it limits replaying.
Having access for 14 days lile a boo kwould be something very different and more OK with me. But limiting the act of playing that audio itself has a new quality for me.
(DRM of course)
Edit: but apparently I was wrong and the "countdown" was just the time left of the audiobook. But the mobile UI was stuttering, so that wasn't clear. But thinking about it, I am surprised it ain't implemented yet for real.
Not everyone had some massive record collection and hundreds of cassette tapes.
Today, those "cool" stations have primarily been slurped up into iHateRadio / Comcast conglomerates, so commercial radio is useless. The internet is the only saving grace for kids today, but even streaming platforms don't do it for me. Sadly, youtube is about the best thing for its ubiquitous availability. Bandcamp/Soundcloud are cool, but still not the same discoverability as YT.
Even with my collection, it's still not instantly accessible as I'd like due to the manual labor of digitizing. I've tried on multiple occasions, but it's only a fraction of the collection. It's just too easy to find it with yt-dl
These platforms aren't necessarily drawing people who really wanted a big privately curated music collection to own forever, they're drawing the people who just want to listen to music and not have to spend much or anything at all for it. Which happens to be a ton of people.
The situation for me on Android would be hilarious if it weren't so saddening. Since I purchased a KitKat tablet in 2015, I've more or less stuck to the "Android Files" app to play music files. Yes, that has been the best solution: no app install required, bare bones, no feature demands from me. In fact, rather than making playlists, I would just copy out tracks to a new folder and play them in there. Want to repeat one? Make five copies of it!
On Chromebook I'm using the builtin app, Gallery. It's utterly barebones as well. All I want to do is listen to a track.
This has continued even to the present day, but you know what? Our days are numbered, because apps are staking out moats in terms of file types they will handle. They're looking to reduce generic handling of multiple file types.
I've been trying to conform to this "new normal" by using YouTube Music. With my Premium subscriptions I should be able to download any streamable track, and also listen to files on-device. This is working out poorly. The on-device management is abysmal and makes you want to die. The downloading feature just sort of... fills up my storage, and I don't really even use it. I still fall back on Android Files because Music is such a horrible app, except when I'm using it to stream.
Software for playing audio used to be great even with far fewer engineering resources going into them. That suggests the reason they are getting worse is deliberate and stems from a misalignment between what software users want and what the producers want.
Most music software companies today are two businesses joined together:
1. A software company that makes apps to let people listen to music.
2. A content licensing company that pays artists and record labels to give them access to music and let people listen to it.
If they were only #1 then they would be agnostic to what music people listen to and how much of it. WinAmp didn't give a damn how big your music library was, what songs you listened to, or how often, because that was entirely between you and your MP3 collection.
But, say, Spotify has to pay someone every time you listen to a song and how much they pay depends on what you listen to and how often. That gives them a direct, perverse incentive to build an app that routes you away from expensive audio you might prefer towards cheap stuff that eats up your time but doesn't cost Spotify as much.
That's why every single time I open the fucking Spotify app I see a wall of podcasts even though I have literally never listened to one and never will. They don't put them there for my benefit, but for theirs.
For Spotify, the end game is routing people towards eventually-AI-generated musak that they themselves own the licenses for because it's free for them. This is directly analogous to why Netflix is now constantly pimping their own often-shitty produced shows over movies you might actually prefer.
The reason we aren't saturated with options is that producing a media app without also having deals that give the app direct access to media to play dumps a lot of work back onto users and most users these days simply don't have a local media library or want to maintain one.
And spinning up a new app that does off content directly has huge startup costs. You need an army of lawyers to go out and negotiate deals with every record label out there, and those labels probably hate you out the gate since they are still salty about not making anywhere near as much money as they used to make when they sold CDs.
And it's funny you point to the podcasts as an example for that, a lot of the podcasts and now audiobooks they push are some of the most expensive content they have.
1. Companies want you to keep paying for the subscription, so they want to offer you things with value.
2. At the same time, since you're paying a flat fee, they don't get much incremental reward for offering you things of incrementally greater value. So their incentive is to cut costs by offering you as little value as possible as long as the value is juuuuust above the threshold where you (well, the aggregate behavior of all users as "you") cancel.
3. Because of lock-in effects like having a huge library of liked songs and playlists in Spotify, being in the middle of binging an exclusive show on Netflix, the threshold of frustration where you would cancel gets higher and higher.
4. Thus, they are incentivized to increase lock-in because it enables them to cut more costs and deliver less value.
As the size of your music library goes up, the UX changes. The original iPod UX was (at least for me) genuinely awesome. It became less awesome as iPods got 40, 60, and larger storage, and it was pretty much unusable when I modded one to have 1TB of storage.
And related but different, everybody's expectation of what "a large music collection" is varies wildly.
I don't necessarily think this is intentional enshittification, I lean more towards "there's no right solution for everybody, and there's probably not even a dozen different right solutions that encompass most people".
And then there's a massive chunk of the market that finds the tradeoff of ads for "free" access to music an acceptable tradeoff. A few dollars a month in cost for access to music is way more than they're interested in spending, even $10 for a CD is more than they're usually looking to spend to acquire content. They're the kind of people who maybe only bought a handful of CDs or cassette tapes back int the day total and got a lot of their content from the radio.
Most of the paying customers for digital music tend to be generally OK or even prefer streaming services. And generally speaking, those streaming apps work pretty OK. Most work better than the early streaming/subscription apps back in the day (like old Rhapsody and Zune Music and non-pirating Napster). I still remember how long it would take to go from clicking Play on Zune to the time it would actually start playing the song compared to Spotify which felt nearly instant in comparison. Not having to reconnect my Creative Zen every few weeks refresh the DRM from Napster. Having all that content on demand from my wireless portable device. Practically all of what is available today is quite a bit better than what was, in terms of "I don't want to bother buying all of this content, I'm OK with renting a lot of it" standpoint.
I've got a collection of music I own, things I really care about. Mostly physical formats, a few hundred songs exclusively digital files. But for a lot of music I consume, I don't really care if I have it locally or have it forever. Its like listening to the radio, that song may never play again, that's OK. Buying all that content legitimately costs considerably more than what I pay for a streaming service, so the streaming service makes a ton of economic sense for what I'm looking for. I'm mostly looking for something in between a radio and a privately curated music collection, which is exactly what streaming is.
On both iOS and Android, HTML can play videos and mp3s while the screen is turned off. So maybe it is possible?
https://stackoverflow.com/questions/64283711
It works nicely in Chrome on the desktop and on Android. Not sure how the situation is on iOS.
Edit: https://caniuse.com/native-filesystem-api
Edit2: Just a few posts down: https://webamp.org/
That's a pretty big argument to go with an Android phone.
Being able to write your own tools in HTML is so nice.
I just never polished it to publish it, but it is quite easy and I guess ChatGPT can help with the basics as no arcane knowledge is required. (Except maybe the playing while screen is off.)
You also need a small node script, though or something different with system access to scan the media files. I think in browser tools make this now somewhat possible without(beware of security restrictions), but my approach is simply a node script scanning the music folder and generating a list that the media player consumes to find files for the player. I still didn't got around to make it automatic, but I don't add so much music (anymore).
I guess I will give it a try to see, how good it works a mobile player nowdays. I always wanted to upgrade it, so I can connect to spotify from my player as I hate the spotify mobile app.
When I made https://ambiph.one I ended up having to route everything through a MediaStreamAudioDestinationNode to trick Safari into thinking it's a livestream, which is apparently the only type of audio allowed to play in the background
Minimal demo here if it's helpful for anyone: https://codepen.io/matteason/pen/VYwdzVV
If you are playing music through Spotify in the background, foreground audio in Snapchat still plays normally while recording and playing back just recorded snaps, as well as snaps or memories you have prepared earlier. Sometimes you need to start playback on Spotify again via Control Center, because Snapchat steals focus or takes priority for audio output or something, but it is just part of the jankyness of this workflow, which is probably not intentionally designed to be used the way I use it. If you combine these quirks with Screen Recording, you can make simple audio loops by recording simultaneously via Snapchat and iOS Screen Recording, then use those videos as uploads to Snapchat to stack the loops over each over by selectively queuing them, with audio from a video in Snapchat playing at the same time as audio from Spotify.
It’s kind of a weird workflow, but it’s neat that it works. It feels intentional, as most apps stop background audio playback when starting recording on the same device, but at least Snapchat does not do this, so it’s at least technically possible.
My hunch is that they’ve got an actual from-scratch rewrite in the works that’s similar to the all-new WinUI-based Windows version of Music that came out a while back.
Apple is so quick to drop support for some things and keep other things around seemingly indefinitely.
https://www.plastaq.com/minimoon
Personally, I sync my music via Synctrain (a Syncthing client). [3]
I was unaware foobar2000 existed on iOS too, but the Windows version is my favorite audio player on that platform too.
Does Apple want to face a formal non-compliance judgment under the DMA, or is there another reason for Apple's blatant contempt of court with its refusal to properly and fully implement the mandated sideloading[1]?
[1] The Digital Markets Act (DMA) does mandate sideloading in Article 6(paragraph 4). It requires designated gatekeepers, which includes Apple for its iOS operating system, to allow for the installation and use of third-party apps and app stores. ( https://eur-lex.europa.eu/eli/reg/2022/1925/oj/eng )
Would love to take a look at your web app if it's available
You can transfer files to the app over wifi or even use files from the Files app.
However, I feel like this is one of the most re-invented wheels I've come across so far. Nobody seems to be happy, everybody seems to fail to build something that fits at least 80% of the requirements most people have.
My personal K.O. criteria is a bit awkward in days of bluetooth and wireless devices: Working cable headphone remote controls like Apple devices had for more than 10 years now - especially useful for audio books.
Years ago I tried to write a cross platform audio player[1] app with C# and Flutter inspired by iPod Nano 7g, but it always failed for the same reason: I could not get the headset controls working properly.
I've also spent some days to submit a PR on audiobookshelf-app[2], but it didn't get merged, although it worked pretty good on my device.
Nowadays I use a combination of my old iPod Nano 7g for music and audiobooks on the go and my Android GrapheneOS Phone as spare device for "streaming" something I don't have with me using Navidrome[3] and Substreamer[4] / DSub[5] for music and audiobookshelf-app[6] and VLC Media Player[7] for audiobooks (the offline support for audiobookshelf regularly breaks on my device) - most of these are available on fdroid or even official app stores.
Btw, if you ever wondered, why Apple EarPods do not support Volume Control on Android devices and vice versa, see this link[8] - it's definitely worth a read
1: https://github.com/sandreas/ToneAudioPlayer
2: https://github.com/advplyr/audiobookshelf-app/pull/1218
3: https://www.navidrome.org/
4: https://substreamerapp.com/
5: https://github.com/daneren2005/Subsonic
6: https://github.com/advplyr/audiobookshelf-app/releases
7: https://code.videolan.org/videolan/vlc-android
8: https://tinymicros.com/wiki/Apple_iPod_Remote_Protocol
https://github.com/nzoschke/jukelab
It's a web app with the Spotify Web Playback SDK or a good old MP3 HTTP server and API like Internet Archive.
It works crazy well on a ChromeBook, and reasonably well on an iPhone, iPad or Android both through a native app with a webview component or the browser.
I have a theory the pendulum is swinging back and there is a demand for controlling our own music and music interface, and web technology is sufficiently good for implementing players.
Or else a large audio file will be halted on the clientside till it is fully downloaded.
I have to disagree. Async may makes concurrent code easier to write, but also less simple to reason about as it grows. In a complex async codebase, I find it harder to reason about code flow and concurrency.
If the goal is to reduce the cost of executing threaded code, we have a solution in green light weight threads.
If we aim to reduce the cost of maintaining threaded code, I expect async to end up costing more effort in the long run.
Good concurrency should make the code simpler to understand and reason about as it grows. Simply having process/service based encapsulation is a huge win. IMO this is a failing of the async/await abstraction, not concurrency itself.
As an ideal.
But you can only go so simple once you have a piece of data that is read at the same time by many, while also maybe mutated by at least one. And as simple you can get version 1.0, as software grow, it gets new features which necessitate more interactions with that data, which makes synchronization more complex.
Dataflow patterns avoid this sort of issue by eliminating shared memory mutation. All data flows through the system by value with mutations only flowing downstream. There are several "Concurrency Patterns" videos by Rob about using these patterns in Go on youtube.