Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Built My Own Audio Player

nexo.sh

Post reply on HN
Print view View original

181–190 of 209 posts

Re: I Built My Own Audio Player

#181

Post by munificent »

vel0city wrote: post #173
munificent wrote: post #50

Earlier quoted context omitted.

It's enshittification. 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.…

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.

Re: I Built My Own Audio Player

#182

Post by jbirer »

This is really cool, I love how you planned the entire development before with graphs.

When I was 16, I developed an mp3 player in C (I cheated and used mpg123 library). Audio players are a great way to learn about low level stuff and as a first project.

Keep developing things!

Re: I Built My Own Audio Player

#183

Post by legends2k »

eviks wrote: post #135
wvh wrote: post #125

I've been building a music collection in FLAC format for 25 years, and last year I bought an (Android) phone and a MicroSD card of 1TB that fits all of my music. It's been a long project for technology to catch up, but now that it's possible to have all of it in my pocket, I'm pretty happy with it. I'm sure I can't be the only one that doesn't want to be a renter, give up control and stream anything the industry want…

Technology has caught up many years ago, it's just that you insist on an format not fit for purpose. With good reencoding you get transparent audio quality (impossible to hear a difference) to fit all of your music on a much smaller card. (and as a backup you can always have those FLACs on the desktop)

Even if we agree on a format I don't want someone to quietly say a song I like is gone from my library while I wasn't looking due to some reason.

Re: I Built My Own Audio Player

#184

Post by hulitu »

eviks wrote: post #135
wvh wrote: post #125

I've been building a music collection in FLAC format for 25 years, and last year I bought an (Android) phone and a MicroSD card of 1TB that fits all of my music. It's been a long project for technology to catch up, but now that it's possible to have all of it in my pocket, I'm pretty happy with it. I'm sure I can't be the only one that doesn't want to be a renter, give up control and stream anything the industry want…

Technology has caught up many years ago, it's just that you insist on an format not fit for purpose. With good reencoding you get transparent audio quality (impossible to hear a difference) to fit all of your music on a much smaller card. (and as a backup you can always have those FLACs on the desktop)

> Technology has caught up many years ago

citation needed. Youtube still gives you crappy, unlistenable 153kbps crap.

Re: I Built My Own Audio Player

#185

Post by eikenberry »

selkin wrote: post #71

> 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 i…

> 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.

Re: I Built My Own Audio Player

#186

Post by TartHint54 »

Loved the deep-dive! Your switch from React Native to pure SwiftUI really drives home how much easier native code becomes once you need proper iCloud access, and the SQLite FTS5 search trick is brilliant—I’m borrowing that for my own library app.

Re: I Built My Own Audio Player

#187

Post by selkin »

eikenberry wrote: post #185
selkin wrote: post #71

> 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 i…

> 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 itsel…

> 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.

Re: I Built My Own Audio Player

#188

Post by teleforce »

soulofmischief wrote: post #108
teleforce wrote: post #106

For me the best audio player ever is Napster [1]. It's not just an audio player but an eco-system, and for better or worst it changed the music industry forever. Perhaps the modern version should make a p2p music streaming from peers rather than direct downloading. [1] Napster: https://en.wikipedia.org/wiki/Napster

Spotify was originally p2p. The early principal engineer was the same dev who built µTorrent, Ludvig Strigeus. I'd also recommend looking at communities such as Soulseek. And Limewire is still around!

Thanks for the info although I was around during the released of µTorrent and one of its early users, I didn't know Ludvig Strigeus was instrumental in the Spotify early days.

Apparently he also the original author of OpenTDD and ScummVM, and it seems that he's the legit Carmack 2.0 [1].

[1] Ludvig Strigeus:

https://en.wikipedia.org/wiki/Ludvig_Strigeus

Re: I Built My Own Audio Player

#189

Post by eikenberry »

selkin wrote: post #187
eikenberry wrote: post #185

Earlier quoted context omitted.

> 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 itsel…

> 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.

Re: I Built My Own Audio Player

#190

Post by duped »

hulitu wrote: post #184
eviks wrote: post #135

Earlier quoted context omitted.

Technology has caught up many years ago, it's just that you insist on an format not fit for purpose. With good reencoding you get transparent audio quality (impossible to hear a difference) to fit all of your music on a much smaller card. (and as a backup you can always have those FLACs on the desktop)

> Technology has caught up many years ago citation needed. Youtube still gives you crappy, unlistenable 153kbps crap.

There are a number of studies on this but this one has a good summary (1). The TL;DR is that over 256 kbps for MP3 there's no significant data that listeners could perceive a difference to CD quality audio. Lower than that you can perceive artifacts.

I'm too lazy for finding this but I recall this study or similar repeated for trained listeners (musicians and mastering engineers) with the same results.

Note that MP3 is 30 years old and newer perceptual audio codecs can beat it.

YouTube picking lower bitrates is a problem but the qualifier here is "at sufficient bandwidths."

(1) https://www.researchgate.net/publication/257068576_Subjectiv...

Post reply on HN