Downloading tracks 2.0

LLK · March 5, 2022, 5:42pm

I’m ok with thought exercices but, here is that really the main scenario we want to provide Downloads for? There’ll always be something wrong until we can provide multiple choices, in the meantime, is our focus really to provide the worse format so that it fits people with a bad 3G connection in a hurry to download a Resonate playlist ? (which they can’t do unless they already own all the songs or buy them which would be the number of songs * 1.25€ and if they already own all the song I guess we could just say they should have downloaded them first which is why in most cases this scenario wouldn’t happen).

And here again I really want to emphasize, do we really believe the people wealthy enough to pay for a resonate playlist in full so that they can download it in a hurry are the same demographic that’s concerned about their spotty 3G internet that they pay for by the megabyte?

I’d be really curious to hear about this, especially about what would the “communal” infrastructures for the implementation of this look like, do we have examples for how these things work etc. ? That’s the part I’m struggling to understand, apart from that yeah anything local community based (basically in broader terms anything that means people could still enjoy some or all the benefits of resonate without solely relying on our monolitic internal server infrastructure) would be great in the absolute.

Also I’ll add this is more interesting than a bad download format because it effectively (in principle) preserves the full Resonate experience (ie. it preserves the low access price to the discovery of songs basically).

Edit :

I want to come back to this because I feel like I’m being confrontational for the sake of it or pushing for “sound quality” (when really I’m not since I’m rooting for a lossy format) like a purist of some sort so I just want to make my opinion clearer because I don’t want it to look like I don’t care about it.

The reason I’m insisting here is because I want us to be clear on something : As it stands, Resonate is NOT a service that’s welcoming for people in dire financial needs and in complicated access to internet situations. It requires a good connection to run because it’s a streaming service, so if you’re by the minute on megabytes in 3G it’s a shit proposition for you, it requires to pay 1.25€ for a song that you could listen to basically for free forever on Spotify, Youtube or whatever so it’s not a good solution for that either. What we provide is an ethical service that comes AT A PRICE. The price is you have to pay 1.25€ if you want to listen to a song more than 9 times. In the current economy, this effectively means we’re a luxury good - like most “ethical alternatives” by the way since they often imply a price increase to feel better about yourself that you’re “supporting” a different/pricier way of doing things, it’s a pitfall we need to think through in its entirety. Resonate isn’t so much an alternative to streaming as it’s a clever way to push people back into the habit of buying the music they like at a premium which is a pattern they’ve abandonned. It means we’ll probably appeal to people with a decent enough connexion, who can shell out money for the music they love in the hundreds per year (if you’ve loved 10 albums in a year, and they’re all 10 songs long, you’ll have effectively spent 125€ on Resonate if you want to own them) OR to people who will have to forget about the option of ever downloading entirely, and just use it as a rather cheap discovery service until they’re absolutely certain they want to spend more (so for example out of the 10 albums they love, they listen 9 of them on other services to avoid finishing their credits, and then listen to the one they trully adore 9 times on Resonate to buy it).

So really, I’m all for us trying to figure out solutions for low wage workers, people with bad internet access, countries with currencies that make a € an extremely high value etc. but we need to find complete solutions, because otherwise, we’ll just propose a worse service for an audience that litterally isn’t there because they don’t even really have access to our platform even if we would love them to.

I’ve been advocating for a “low wage option” on the platform where we basically give away credits or make credits much cheaper if people tell us they can’t pay right now because they’re poor but would like to use the platform, although I’m aware this opens the door to an entire subset of questions, but however I put it, I’m more interested in the question of how we can provide the best experience to folks without the means to usually access them.

thehouseorgan · March 5, 2022, 8:15pm

My 2¢

I’ve been fortunate enough to spend time in several ‘resource poor’ countries in the ‘global south’, both rural and metropolitan, and the only place I’ve ever truly experienced unusable mobile internet (beyond temporary dead spots) is in North Wales in the UK. The reach of mobile data and its availability, at least in my experiences, is quite far and wide. There may well be blind spots in my experiences but that’s my take away.

I personally think e.g. 128k mp3s diminish the audio so significantly that it would compromise the coop’s role in caring for, and responsible stewardship of the artistic vision and craft of our members.

I agree that thinking about equality and access is important but I personally don’t think mp3 filesize is that useful an area to tackle this.

I do however appreciate @ryanprior raising these concerns, despite disagreeing over the approach.

LLK · March 5, 2022, 8:32pm

I appreciate this a lot too sincerely, I hope I made it clear enough and fear I haven’t.

Zamomin · March 10, 2022, 2:48pm

This makes a lot of sense to me.

I would like to add a couple more points to the discussion concerning the question “Can artists opt out of offering download?”. I have read the manifesto and it seems to me that article 7 clearly points to “Yes” as the answer.
This might settle the issue (I’m too new to this community to assess this), but if it does not, I would like to point out that currently there isn’t an ethical alternative for a streaming platform, but there also isn’t one for a digital music store. If offering a download would be mandatory, Resonate could cover both bases.
I know that I’m a dinosaur in this regard, but I (for the most part) still buy music instead of streaming it. I don’t know many others are out there, but my guess would be that there are a few. If not, Apple would have closed their digital store a while ago.

goaty · March 13, 2022, 5:32am

My thoughts:

Bitrate: Would 256k MP3 be a good compromise? 128k sounds pretty awful and, as a listener, I prefer 320k (or FLAC), but I think 256k sounds decent enough for most people.

Should artists be able to opt out of downloads? I think no—part of what’s so interesting about Resonate to me is that you “own” the music after 9 plays. To me, an essential part of owning the music is being able to store it locally instead of relying on the service being up.

blackthorn · March 14, 2022, 1:56pm

I’m a listener and a musician. I’m writing from my personal listener account, but I also make music with an artist on resonate.

I’m not especially interested in streaming platforms – I’m here because I believe strongly in the co-op model, and I’m hoping that resonate can become a download shop as well as a streaming platform.

I’m coming from a paradigm where music is not disposable. In my world taking 200 person-hours to make a music track would be a reasonable minimum, and listening to a good album hundreds of times over decades would be quite normal.

From my POV streaming is something that corporates invented to maintain their control over the music ecosystem, continue to extract money from back catalogue, and gather data on listeners. As a result I find the whole idea of streaming for my regular music listening a little gross. (This isn’t intended to diss anyone who finds genuine value in streaming for regular listening, just explaining where I’m coming from)

There’s one exception – browsing for new music. Streaming platforms are great for finding something new and perusing a lot of music quickly, often only playing part of a track and moving on.

If I find something I like on a streaming platform, I want to buy it and download it within a dozen or so clicks. That could be by way of a link to direct sales from the artist’s website (remember when people did that?) – or it could be buying from the streaming platform. However if I find something I like and I can’t buy and download it in full lossless quality, it goes on the too-much-trouble list and I move on.

If I buy an album or a track, I expect to be able to download it in full lossless quality (preferably flac) to be stored locally, moved between devices , burned to CD, or whatever I need to listen to it. Anything else is not ownership of the track.

Of course there should also be an option to download in a smaller lossy format for listeners with limited devices or suffering from corporate capture who can’t play flac.

For an initial offering I think flac plus one lossy format would be an absolute minimum. (Look at all the choice of download formats bandcamp offers for comparison.)

I think, in the spirit of freedom, that artists should not be absolutely required to offer downloads, but I also think that allowing downloads should be the default, and artists should be strongly discouraged from disallowing them in most cases – why alienate your most serious listeners?

As a musician, I care about piracy, I guess - but realistically – if someone wants to pirate the track they will. They can simply record the stream ffs. The best anti-piracy measure is to make it convenient and rewarding for listeners to pay.

I’d also rather someone listened to my music and didn’t pay, than didn’t listen to it. If they like it they might come back and pay for it or something else later. I believe that most piracy is not a choice between a a person listening but paying or not paying. It is much more often a choice between them listening or not listening.

A pay-what-you-feel option (with a minimum) as on bandcamp is also a no-brainer for me. This idea could be extended, for example there could even be a suggested “normal” price above the minimum as a guide to what a waged person in a western/wealthy country should pay.

A bit more about quality: As an artist I would like people to always hear my music in the quality I released it at – so lossless should be available wherever the devices used make it practical and worthwhile. Lossless music streaming is quite practical on a real computer with a decent net connection. It is way less bandwidth than streaming a 1080p movie.

As a listener I’d also like lossless streaming when browsing for new music, however since I would intend to download the lossless file when I find something I like, it is maybe less important. If I can’t download the file, then my interest in the whole platform wanes, but also the need for lossless streaming is greater.

The obvious solution is to have a user-switched resolution button for streaming – that perhaps defaults to the lossy format, but allows listeners to get the full version. This is an audio equivalent to the choice of resolution that youtube allows.

blackthorn · March 14, 2022, 2:04pm

Just for clarity, and reinforcing what some others have said, here’s a note about file formats and flac

Flac should be the no-brainer default format for music storage, archiving, and playback, including streaming on capable devices and connections with good bandwidth.

Here’s why:

It is full lossless quality - same sound quality as wav, alac, or aiff
It is a free open non-proprietary standard
It is smaller for storage and transfer than uncompressed standards such as wav or aiff, with no loss of data or sound quality.

Places where is is appropriate to use a lossy compressed format instead are:

Streaming with limited bandwidth.
Storage on non-audiophile devices with very large libraries and/or severely limited storage space (ie older ipods, phones etc)

Places where it is appropriate to use an uncompressed lossless format:

Music production where many tracks will be played back at once and cpu power (for decoding the files) is at a premium.
As a workaround for people or devices tied to corporate standards that don’t support flac playback.

LLK · March 14, 2022, 2:15pm

Just to be clear, I think this is something everybody hear agrees on for the 1.0 version of Resonate when the platform is fully operationnal.

The question being asked here is, during the beta period, which format should be implemented first?

My take is MP3 320kbps is good enough (and I’m a musician so, I too want people to experience my work in the best possible quality, I just think nobody will notice any difference between 320 and Flac when listening to my songs) to be the first implemented format because it’s both convenient for us in terms of storage and a broad and accessible format for anyone to use. And Flac should come second when we have the download feature in place.

And when the platform is out of Beta, we should have both as a baseline minimum option.

blackthorn · March 14, 2022, 2:32pm

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.

blackthorn · March 14, 2022, 2:38pm

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?

LLK · March 14, 2022, 2:52pm

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.

blackthorn · March 14, 2022, 3:39pm

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.

blackthorn · March 14, 2022, 6:39pm

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.

LLK · March 14, 2022, 7:35pm

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.

Hakanto · March 14, 2022, 8:23pm

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.

thehouseorgan · March 14, 2022, 9:39pm

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.

Nick_M · March 15, 2022, 7:41am