mrmufungo

Hey, no problem!

I bill the site as more of a music streaming and storefront service. It's much more in-line with services like Bandcamp and Soundcloud, where users can upload their own music. The site leans more towards Bandcamp in that users can monetize their work, and the site takes a very small fee for transactions. I'm focusing more on community aspects, like remix and sample competitions, as well as live music sharing, to help differentiate it even more.

Two years ago, I posted a Show HN about a music streaming service I've been working on for about four years at that point. It was my first serious project I've ever worked on.

Check out the Show HN: https://news.ycombinator.com/item?id=20309255

I'm still actively working on that project, and a countless number of features have been added. Yeah, a few people here and there use it, and it is costing me about $100 a month to host on AWS, but I'm not bothered. I'm still very passionate about this space, and nothing else really interests me as much.

If anyone is interested in checking it out, the site is https://ampl.fi/

Noted!

Noted!

This is doable. If implemented, what would you like to see? I imagine whatever the notification system would show, e.g. uploads from other users, comments, etc.

You have a Collection, which is where music you've purchased resides. If an artist decides to remove their track, but you purchased it, it's "soft-deleted" - the artist themselves cannot access the track, but you still can.

At the moment, the upload limit is 15 tracks a month. Since this is a subscription-less service, there's no way to subscribe to a plan for unlimited uploading. We can always override the limit on a per user basis, depending on your needs.

The revenue model of Bandcamp, the interactivity of SoundCloud. I think that's how I would describe it.

Unfortunately, Safari does not support Opus-encoded audio using the Web Audio API. I actually had to push a hotfix earlier this week since Safari uses webkitAudioContext as opposed to AudioContext (which I wasn't checking for) - the site wouldn't even load.

See this issue:

https://github.com/goldfire/howler.js/issues/706

I could fallback to something like MP3, which is something I'm looking into.

I really need to add some type of alert for users using Safari, at least for the time being. Thanks for reminding me!

Not a stupid question at all! I actually looked into byte-range requests as opposed to downloading individual segments, indeed Amazon S3 does support byte-range requests. I would think it's similar to implement, and wouldn't have as many moving parts.

When I had started the project, I saw how other streaming sites fetched their audio, and I saw a pattern in individual GET requests for segments. I thought, "Hey, they're doing this for a reason, and even though I don't fully understand this reason, maybe I should do it to." At the time, I think I justified it by thinking that someone who wants to rip the stream file would have to piece the track together versus just requesting the full track.

In the end, it really doesn't matter: anyone who is willed enough can get whatever is being sent to their client. It's one of those moments where I didn't bother to really think it through and factor in the practicality aspect. I'd like to go back and re-visit byte-range requests, though, just to see how it would work differently.

I'd label it as a music player and a store. You, as a listener, can browse the site and purchase music to add to your collection. Artists are listeners to, so they can do the same thing, but they also can upload their own music and monetize it. Aside from that, it has the basic functionalities you would expect from a site like this: favoriting tracks, creating sets, commenting - the typical stuff.

Honestly, I wasn't sure how to label it myself: I'm terrible with describing things. I'll be sure to give it some thought though.

The backend is pure Java, and is composed of four separate microservices. The web server (we use Javalin) is nothing special; the transcoder works as follows:

* An POST request is sent to the web server. If the file is valid, it is moved via FTP to a local server. I then create a message for RabbitMQ to add to a transcode queue.

* A worker listening on the channel gets the job, and does all the needed work to make the file "streamable", e.g. segmenting and encoding file parts, creating the M3U8, generating the waveform, storing to S3, etc. Throughout the process, progress is saved in Redis, which is made available to the client for visual feedback

* Once the process is done, an identifier is generated, which the client refers to when saving any modifications to the track information. We primarily use MariaDB.

The transcode process is the most complex piece of the puzzle, of course. Everything else is pretty much CRUD operations.

Sure. The site is billed as a delivery service, thus you're able to upload music (that you have the rights to) and monetize it. You could, of course, opt to give away your content for free; there's no requirement to login or perform an action to download a free tack. The site does allow remixes and mixes, but they have their own rules.

In terms of interaction, it's similar to SoundCloud. I've been using SoundCloud for years - just right after they transitioned to their V2 site. I've also used Bandcamp for selling my own music, and always felt their approach was transparent and fair when it came to monetization. When I started this project, a little bit of both went into the design and structure.

This was initially a project I had started to get better acquainted with the Web Audio API. I had done some preliminary work with the Media Source Extensions API and piping output via to the Web Audio API, but I wanted to see how well the scheduling capabilities were. Throughout the effort, I learned quite a bit about signal processing and FFT.

The current process is rather simple: I utilize M3U8 for storing segment information, and manually parse the file when a play request is received. I grab the first few (Opus-encoded) segments, pass them through an OfflineContext to maintain a specific sample rate, and store the resulting buffer in a wrapper object. Each object is stored in an array, and is responsible for re-creating the AudioNode when stopping or starting.

The hardest part about this (for me at least) was fetching and scheduling accurately while the player is running. I group segments requests together, and schedule after each group has finished downloading. It's not perfect, as I occasionally get pops between each segment: Chrome seems to be less noticeable than Firefox in this regard. I schedule based on the buffer duration, but there seems to be subtle differences between browsers.

In any case, I've had quite a bit of fun working on this project.