Downloading tracks 2.0

Is there a technical difficulty in offering both at once?

I have no idea of the answer, but to avoid future technical debt, it would be good for the platform to be coded from the start to support multiple download formats.

I’m imagining a system where the master copy is stored as flac, and a secondary copy is stored in the lossy format used for the stream. (or is it created on the fly?) This gives two versions ready to go at all times. Further formats could then be created on demand from the flac master when a download is requested.

I guess in suggesting where to start it comes down to what formats are currently used in the archive and whether the storage and encoding paradigm needs major change or just adding to.

The guts of what I’m trying but not quite managing to say in the last post is that there must somewhere be a master version of the track in a lossless format, so why not allow the listener to download that?

Basically yes.

It is my understanding that this is a non trivial dev job that requires some amount of time and is not just a matter of adding/exposing a “download” button to the format used for audio streaming. It was the answer I got when creating this thread and discussing with the dev team.

Which is why my main goal here is to :

1/ find the lowest threshold of difficulty solution to implement so that we can actually call ourselves “Stream 2 Own” (the minimum being that people actually “own” something, whatever that something is).

2/ that this solution is satisfying enough to then leave enough headroom for the devteam and volunteers to focus on a longterm solution taking the time they need to do so.

I can ping @auggod @angus @Nick_M (or @boopboop ? Is it an aspect you’re familiar with?) for more infos on the technical side but I know they’re busy so maybe we should not expect too much from them.

Well ok - without understanding the actual technical blocks to delivering downloads we are all just speculating.

Were the technical issues ever discussed? I’d like to know out of curiosity at least.

I’m not that concerned about what format should be used if we have to pick just one.

I am however very concerned that the fact that we have to pick just one indicates deep problems in the way the audio files are stored and handled.

It suggests that there isn’t a master database of lossless files, and/or that there isn’t an automated system for converting from a definitive lossless version to the version used for streaming or downloading.

I’m therefore worried that pursuing a stopgap solution for downloads will push a real solution even further into the never-never and further embed an unsatisfactory infrastructure.

Currently resonate deals with at least two files in some way: the master uploaded by the artist, and the file streamed to the listener. (which might be created in real time for all I know) Yet neither of these are readily available for download. The process of converting one to the other may not even be automated. It seems to me that this structural problem needs addressing first and then multiple download formats would fall into place relatively easily if that were done.

1 Like

It’s being adressed and worked on and everyone is very aware of all of this believe me.

You need to understand that right now, the dev team is very small, and that’s why our focus is on trying to get some fundings to do exactly all the things we are discussing here.

Right now you should go with the prerogative that NOTHING is easy. We have a lot of things that work, and there are a few very talented people helping out, most of them volunteers, to help turn this into the best possible experience it could be, but working on the backend infrastructure, including metadata handling, catalogue import for big distributors etc. is not a trivial task, and there are a lot of those.

So basically any dev time on anything comes at the detriment of any other similarly crucial endeavor. So that’s why first and foremost we need, to put it bluntly, money to pay devs.

PS : There was more of a talk on the matter here Offer track downloads which is what sparked this Downloading 2.0 topic.

1 Like

Not a fact, rather an invitation by me that we focus on picking one format, implementing it to solve the main problem (not offering downloads) and then iterate adding other formats or features from there.

I was aiming to shrink the scope of the project with the hope it would make it easier for devs to approach.

@peter or @auggod could likely offer clarity here. I’m not a developer myself – more of a facilitator and coordinator around here. If there are structural issues which need addressing first, then I imagine those issues will be part of implementing this plan, regardless of how many file types are offered.

Thanks for your reflections on this.

2 Likes

Agreed, we would benefit from a better understanding of the tech systems involved.

There’s some tech documentation here though - Exploring Resonate's technology architecture

Sorry, I think this is somewhat unfair. We’re picking only one so as to focus developer work into a specific first step, not because there are problems with files storage or the tech stack.

WAV, AIFF, or FLAC are uploaded. I presume there is a transcoding process for the compressed stream format. There’s no suggestion that original HQ files are not kept in storage.

I don’t imagine that exposing long-term stored HQ original files is trivial. Are they kept in active cloud storage or are they in archive cold-storage? If cold-storage, retrieval isn’t instantaneous. Storage costs money and so cold-storage is common for such archiving. Making these available, on demand, for download, would presumably require rescoping such storage.

When it comes to making a converted file available for download, is this happening at upload, and stored for retrieval? Or, as it seems to happen on Bandcamp, does download trigger some kind of transcoding runner that converts the files only when needed (with some obvious caching probably around more popular downloads)? Depending on the choice requires permanent storage of transcoded files or setting up server-side processing. If we’re opting for storage of transcoded files, that’s more on-demand (rather than cold) storage and associated costs. If transcoding on demand, there will also need to be task runners to clean up and minimise storage.

Say we’ve solved all of those problems, we now need an interface/UX to allow downloading, it needs tying into user credentials to only make ‘owned’ tracks available, it needs to connect to payment/credits systems (to allow buying the download if you don’t already own it), and it needs to look and feel good to use. That’s further development work on the player, not just the backend.

Doing all of that for multiple file types is significantly more work. Once the bugs are ironed out for one file type, the work to do the next file type should be significantly easier as many of the bugs will have already been worked out.

That’s my take anyway.

5 Likes

Related post here:

Need to allow for the effort in re-contacing artists and re-uploading old files of poorer quality.

3 Likes

My vote is FLAC and 320 kbps MP3. Keep it simple. If anyone wants an alt format than those, there are plenty of apps that can do conversions from the FLAC which is lossless. (I’ve also been confused for a long time as to why this is an issue.)

2 Likes

That’s particularly interesting, do we have much stuff where we don’t have original WAV/AIFF/FLAC?

Agreed, do you have any input on Hakanto’s original question regarding how much harder it is to do both at the same time, rather than start with one and then add another?

That’s a question for @auggod :slight_smile:

This is the only bit I’m questioning. I’m not questioning at all that offering downloads properly is a lot of work for all the reasons you mention which indeed correspond with my own understanding.

Sure start with one file type - there will be some custom code for each additional file type, but if each file type requires lots of custom work then it would seem to indicate a structural problem. So (I’m hoping) each additional file type should follow on from the first within weeks rather than months or years.

I also agree we don’t need all that many file types. Flac can be converted to anything else - so really as long as flac plus a universally accepted lossy format like mp3 is there then it is pretty much covered. Anything more is just convenience. Even the single lossy format is just convenience for those who can’t or won’t use a transcoder.

No, that’s cool, I think there’s broadly agreement in this thread.

I don’t know if there is a standard procedure for settling on an agreement for a proposal. If there is, please point me towards it. (I looked in the Handbook section and couldn’t find anything.)

Hence, to help with settling on a consensus I read through the thread and took notes on the opinions of each poster (as far as I understood them).
In the following I list each of the proposed options, the number of votes it got in parantheses and list each poster that I understood to vote for this option.

File Format

MP3 320 (7): @LLK, @thehouseorgan, @datafruits, @Zamomin, @remst8, @goaty (personal preference), @peter
FLAC (3): @Hakanto, @blackthorn, @peter, goaty
MP3 (1): @Hakanto (did not specify a preferred bitrate)
MP3 V0 (1): @thehouseorgan
MP3 128 (1): @ryanprior
MP3 256 (1): @goaty (as a compromise)

I did not take notes on whether people argued for implementing two or one file type in the first iteration. However, that is probably for the devs to decide.

Let artists opt out of downloading

No (2): @goaty, @Zamomin, LLK
Yes (1): @blackthorn (but make download option the default), ryanprior (but not within the S2O model, offer them an alternative that is closer to a traditional digital music store)

I don’t know how to translate this into a vote, but I want to re-iterate that article 7 of the manifesto points towards “No”.

Sorry for all the pings, but I wanted to give everyone a chance to speak out in case I misrepresented their opinion in this post.

2 Likes

By the way about that I’m very surprised I must admit that people could even be ok with artists being allowed to not offer Downloads.

(it’s also been evoked here)

Could we imagine people going to a store buying a CD/Vinyle and then the seller tells them the store will keep the CD/Vinyl because the musician opted out of people taking them out of the store, but now that person can come to that store anytime and listen to the CD/Vinyl as much as they want?

Like, we’re selling Stream 2 Own and we’re saying artists can benefit of Stream 2 Own and yet not offer the listeners who spent 1.25€ on their songs or 20€ on their albums to actually own the music in the end?

That seems REALLY bizarre and at odds with what we stand for to do that for me, it’s like we’re clearly pushing the rights of the artists before the rights of the listeners.

To me if an artist doesn’t want to offer download it’s ok but then… They shouldn’t benefit from Stream 2 Own, maybe we should have another tiers or whatever (like it goes incrementally by x1.3 instead of by x2 every listen) I don’t know.

Personally I would just say make it mandatory. How is bandcamp doing it? Is Bandcamp offering the possibility to just sell unlimited listens? I’ve never heard of it, it would he confusing.

1 Like

Preserving choices for artists is a crucial element of the manifesto and I think it will drain trust if you don’t treat that as ironclad. Therefore I think it might make sense to allow artists to opt out of stream2own entirely, in which case fans can buy a track (or album) outright, with 45-second track previews, but don’t get a streaming option.

But for those artists who opts into stream2own, it seems nonsensical to offer choices about what the owners can do with the music they bought. In fact there’s no choice: if a member pays the asking price for the music, and they own it, it is inappropriate to restrict what they can do with it.

In other words, denying a member the option to download music they purchased through the platform breaks the fundamental contract (in the social sense) of a marketplace, so artists who don’t consent to that arrangement should not opt into Resonate’s streaming platform at all. To give those artists a meaningful choice under article 7, the platform should offer an alternative arrangement from streaming, perhaps similar to what Bandcamp provides.

2 Likes

I actually agree with that, my personnal preference would even be that my music is free all the time, and people can buy it and yes :

It sounds a lot like Bandcamp… Because it is.

Right now my music is free because I don’t want people to pay a high price for music they can’t own.

Sadly right now, when music is “free” people can’t buy it anymore! Because the “free” option is currently just considering that the person has listened to 9 time and already paid.

I’ve heard a lot of people who just want their music to be free so people don’t feel pressured when listening to it and who just want an alternative place to Bandcamp to point people to their music. And right now on Resonate they don’t have that option so the platform isn’t a good fit for them.

Obviously the fear (justified I think) is a race to the bottom where everybody makes their music free in fear of not being competitive if they lock their music behind a paywall when a lot of other people offer it for free, and then the whole concept of S2O becomes irrelevant and we’re just a new version of Bandcamp with an actual streaming UI.

This is one of the reasons why I made this topic

2 Likes

I’d include me as voting for FLAC, too. I think having the option of lossless (and options in general) is good as a long-term goal—but I think for minimum viable product, 256 could be a good midway point for folks who want to be able to download quickly without sacrificing quality too much.