Downloading tracks 2.0

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.

responses to a few things that have been mentioned:

Bandcamp is a pretty good platform as far as platforms ever can be. It is one of the few platform services I can bring myself to use at all. The functions provided are pretty close to what i would want to see. If it were a artist/worker owned coop there would be no need for resonate IMO. So, while we shouldn’t imitate it’s features blindly - if Resonate ends up looking a lot like bandcamp in terms of function, I’ll be pretty happy.

In terms of selling - free music and price, I think a pay what you like option, with a minimum (which can be zero) solves the issue, from a technical perspective. Race to the bottom is another thing, a social problem rather than a technical one. It would also be nice to have the option to pay an artist more for a track/album after purchase. A sort of “this music has grown on me and I want to pay more now” option.

I don’t like the idea of artists opting out of downloads. At all. As a listener I couldn’t take a musician seriously who did that. However it seems to me that article 7 really dictates maximum artist choice. it points towards yes, not no.

Artists should retain all ownership and rights, be able to decide what, when and how they make their art available to the public, and the value of their art.

But if the community decides to make downloads mandatory I won’t be complaining.

I don’t actually care what format is implemented first, as long as a lossless format is available within a few weeks of downloads becoming available.

My preference for flac first is based on the following points:

  • flac can be converted to mp3, but the reverse is pointless and misleading.

  • a master definitive lossless version needs to exist as a source to create the mp3 in the first place, so exposing that should actually be less work than creating the mp3. Sure that master version might be currently archived, but we know it needs to be made available at some point so why not start at the logical beginning, with the definitive version of the track?

However that is really up to the devs how to approach the structure.

I would suggest that these just be flagged and then basically ignored in whatever way is convenient, until such time as an automated upload system for artists is in place, at which time all artists with lossy master files could be prompted to reupload. But this suggestion is predicated on the notion that only a small proportion of the current catalogue has a lossy master.

I’m also wondering, could some dev work be saved by requiring artists to upload flac files with correct tags already in place? The current manual system required me to enter all my tags into a spreadsheet - even though I’d already added them to my flac files.

My point is that requiring artists to stick to a standard format isn’t all that onerous, and artists can be helped with a how-to guide written by someone (like me) whose time is at less of a premium than the devs with detailed knowledge of the code. I can’t help the devs write code to cope with messy and incorrect uploaded files, but I can write a guide for artists to help them upload correct files that require less processing.

It also occurs to me that there might be rare special cases where no lossless master exists. Maybe odd ephemera such as field recordings made on a phone or something. Do we exclude these, or maybe allow them with a flag that basically says “lossy master”. If the slot that holds the (normally flac) master file were to be made format agnostic then it needn’t compromise the structure.

2 Likes

OK so this is OT, but I’ve had a look and I’m not sure if there is another discussion of these issues or even where to look for one. It is an important topic though.

At this point Resonate is primarily about software development - and those of us not equipped to do that are really spectators, hopefully helping, but likely also getting in the way or just wasting time in speculation.

It would be great if there was some sort of overview for non-devs of what resources are required to achieve any specific goal, as I feel that the rest of us can’t really help if we are speculating about the software issues.

I’d like to know, for example, things like how many person-hours per week/month are currently being spent on dev work, how many are paid and at what rate, how many hours might be expected to be needed to reach particular milestones and so on.

Also how many additional hours the current devs would be able to put in if payment were available?

If work were to be accelerated is the bottleneck primarily money or is it primarily available people with suitable expertise?

I know I personally would be prepared to donate/invest more money if I knew what it might achieve. (not that my personal financial contribution will ever amount to much)

I’ve donated to a few worthy FOSS projects that never reached version 1.0 - no doubt others have has similar experiences - so I’m looking for ways to avoid that here.

2 Likes

I feel we should fork this into its own topic, but I’ve had the same issue lately, where basically I largely feel more like I’m getting in the way and even to some degree, annoying the devs, rather than really participating or helping. I think in a way, despite all desires of being a coop, a democracy or whatever we aim for, Resonate is still very much done first and foremost by a little team of devs, and right now I think its mainly “their platform” rather than the platform of the community, because “the community” as a whole doesn’t have the financial bandwith to garantee fair payment of dev time, and since we don’t have that, we can not in all decency ask anything of them that they do not feel inclined to do.

I really feel like I’m stepping on people’s toes everytime I mention something to be done regarding dev at this point because I’m aware I should either have the knowledge to do it myself, or know for sure that everybody’s being paid fairly and that there’s a legitimate democratic process to make sure of what the majority of users on the platform wants so that funds are allocated according to collective decisions and so that the devs don’t feel like they’re forced into doing something they don’t want to by just a few people on the forum that they potentially disagree with.

Right now I don’t feel like we really have either. So it makes talking about anything look more like a thought exercice rather than an actual conversation.

I always post messages here with the assumption that whatever I say might be useful 6 months or 1 year or 2 year further down the line and has no real immediate purpose, but doing that feels a bit like making constant pointless criticisms since there doesn’t seem to be much we can do about it and the entire pressure to actually build things is on the shoulders of 2 or 3 people.

9 Likes

Insightful as always @LLK you very accurately described the raw reality we’re in.

The only bit I’d add to this is that often it’s not even about what the devs want, but rather what the code needs. With software development of this size and scope, they’re constantly running up against compatibility issues across a wide variety of codebases and technologies which have domino effects throughout the system. (And that’s a simplistic overview. Would have to write three or four more paragraphs to even begin to outline.)

3 Likes

Likewise, while I did a first round of testing and responding to some notes/ideas, I’m wary of putting too much onto volunteer devs; it risks getting out of control & too big to handle. IMO it’s better to have a focused set of high-priority must-haves + wishlist than everything in one bucket.

Sorry if this has already been said…

1 Like

I have very limited experience with making software - but still this is absolutely what i found when I have - at least 85% of the effort goes into understanding and connecting to the frameworks of pre-existing software that one is trying to use and build on. The more different such pre-existing modules or frameworks in use, the worse it gets.

It is easy to get trapped on local maxima where to add an unanticipated feature it would be best to entirely replace or reconfigure some piece of incorporated third-party software - but this would require major rewiring of the whole project.

Other than having a fixed feature set prescribed in advance, I’m not really sure how people avoid this.

It suggests to me that as a community we need a clear idea of what the core features should be, and we needed it from the start - but better now than later.

Resonate doesn’t have to be all things to everyone - a decision could be made, for example, not to have downloads at all. If that kept the scope of the project manageable it might even be worth it.

While I personally wouldn’t be much interested in such a platform, others obviously would be. The question is really whether the reduced complexity and reduced appeal result in a more viable ratio than making a more full featured platform.

2 Likes

the closest thing I have seen to a spec for what is being created is this:

2 Likes

FWIW my personal feeling on the download question is… that it’s not an urgent issue in the DSP development essentials. Offline listening would be great, but so long as the music you’ve paid for in full is there for you in resonate on demand, in 2022 the download/ownership question is just not that modern. Plenty of people never own or will own music, they will only ever stream it or access in the cloud.

So while I fully support Resonate having download capabilities, in the future, I think more important concerns are things like… handling metadata correctly, automating inputting of releases, automating payments and reports, giving artists control over their releases and information. All are bare minimums from an industry perspective.

A streaming platform can be just a streaming platform - a sale platform can be just a sales platform. In the future Resonate can and will be both, but from a dev/platform/catalogue perspective, downloads aren’t as essential to our future as many other things I’ve described above and in the DSP overview.

4 Likes

Hope it’s helpful. Happy to add in missing ideas and feed in essential thoughts and questions to that document as needed.

2 Likes

so, contrasting this with my attitude expressed in the first half of this post: Downloading tracks 2.0 - #19 by blackthorn

I think this is a central existential question for Resonate. (though I would regard streaming as a post-modern phenomenon, rather than a modern one)

Selfishly - I would like to know if being a download shop as well as a streaming platform is something the community thinks is important and something the devs actually wholeheartedly want to do. Because for me it’s central.

I’m not going to argue further about it one way or another - but in terms of where I put my energy I’d like to see it resolved. I’m sure the devs also need it resolved as it has major backend implications as we’ve discussed.

2 Likes

it’s important to the coop members & planned be done. but there are things ahead of it in the priority queue that are physical barriers to the downloads - like metadata handling, auto reporting payments, legal agreements etc. those have to be cleared before we can enable downloads.

3 Likes