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

Archiveteam are backing up SoundCloud

archiveteam.org

Post reply on HN
Print view View original

221–230 of 230 posts

Re: Archiveteam are backing up SoundCloud

#221

Post by voltagex_ »

mdaniel wrote: post #220
voltagex_ wrote: post #144

Earlier quoted context omitted.

Generally, if you "stream" (send) me bits, they're mine to do what I want with (practically, maybe not legally). Although, if anyone could tell me how to do that with AES-SAMPLE HLS video, I'd be very happy.

Can you describe the ways you have attempted, and the bad outcome, to help focus the answer/search a little more? The 10 minutes I spent poking around to see what "AES HLS" was made it appear that a MITM proxy would straighten that problem right out, unless you are in an iTunes FairPlay-esque encrypted to your iPhone type deal, in which case I believe the math is against you

One of the issues is that the stream I have as an example is geo-restricted to Australia.

https://au.tv.yahoo.com/plus7/screenplay/-/watch/36206022/sc...

youtube-dl seems to find the stream URL okay, but then prints ffmpeg errors:

https://github.com/rg3/youtube-dl/issues/11636

https://github.com/selsta/hlsdl should be able to do it in theory, but it looks like WideVine DRM is involved.

Someone has a Kodi plugin to make it work but Kodi doesn't support recording of any kind (?)

Re: Archiveteam are backing up SoundCloud

#222

Post by Whitestrake »

Steeeve wrote: post #201
beardicus wrote: post #94

Earlier quoted context omitted.

Archiveteam exists mostly because your suggested course of action rarely works.

If they can't convince soundcloud it's a positive, they should not be doing it.

I don't think SoundCloud is an entity with some optimistic face you could approach and convince through reason or merit.

I expect they, like any business, would take a stance primarily based on liability, cost, benefit, etc... overriding how anyone working at the company actually feels about it.

It costs them nothing to ignore/outright reject without consideration a crazy proposal like "lets give our entire database of content to a third party". Assessing the technical and legal ramifications of that proposal costs time/effort/money. Why bother?

If SoundCloud gives their content to Archive Team, they're shouldering the possibility of some kind of liability, surely. If they say nothing, let Archive Team take it themselves, from their website, they let Archive Team (who understand and are willing to) take responsibility for that.

Re: Archiveteam are backing up SoundCloud

#223

Post by tscs37 »

roblabla wrote: post #72
snsr wrote: post #61

Earlier quoted context omitted.

> As long as there is a single party interested in content hosted on IPFS , the "IPFS Network" will persist. I imagine that's one of the reasons why it's not ideal for archival content.

I don't get why ? It's exactly the same today : you need at least one party to host the data (in this case the archive team). With IPFS however, if more parties wish to host it, it will lighten the load.

There is no incentive to keep data in the network.

You can pay pinning services, but what's the point if you're just going to pay someone hosting it?

I'd rather have this archived on Siacoin, Storj, Swarm or any other distributed network with actual incentives to keep things around

Re: Archiveteam are backing up SoundCloud

#224

Post by cyphar »

0xcde4c3db wrote: post #130
cs2818 wrote: post #103

Earlier quoted context omitted.

I always encrypt because I worry an automated copyright scan will be the end of my account. If there was a policy that assured my non-shared files wouldn't be subject to these scans I would happily store content unencrypted. For reference, I don't store pirated content, rather content that I have a license for, but cloud providers have no way of knowing that. Unfortunately the dispute processes are unreliable, so whe…

> For reference, I don't store pirated content, rather content that I have a license for, but cloud providers have no way of knowing that. I'm pretty sure that they just assert that the backup is illegal even if it came from a licensed copy. One argument (used by Nintendo IIRC) is that the official media/servers are too reliable to require backups, and thus anything purporting to be a backup is really for another pur…

You often see that cloud services or streaming services are creating policies and DRM around copyright laws that actually remove freedoms given to you under copyright (fair use for example, or even instances where you have licensed copies).

I wouldn't trust such services to respect your rights in any capacity. In fact, I would argue that the "our incredible journey" trend is a form of property damage (a storage rental place can't just burn their store to the ground with customer's posessions still inside).

Re: Archiveteam are backing up SoundCloud

#225

Post by CharlesDodgson »

nextlevelwizard wrote: post #75
CharlesDodgson wrote: post #56

Does anyone feel that this is all a bit pointless. Like is there a greater social need to preserve SC? I found a lot of the content to ephemeral, things like podcasts or DJ mixes. I dunno, it just seems a bit silly to put resources on it.

Someone might have poured all of their creativity to content on that platform and to loosely quote Jason Scott "this might be the largest audience this specific line of genes have/will ever reach". Is that not worth preserving? Even if it just takes a thumb drive worth of space? Even if the content sucks, it still part of our history as a species. Think of some of the old works/diaries/letters that are now thought to…

i guess it's subjective, some people would think a bank of Vapourwave music on SC is important. I'm pretty happy to have a 128kbp version of blink 182 albums on my backup, because they mean something to me. I'm just really questioning the need to archive for the sake of archiving.

Re: Archiveteam are backing up SoundCloud

#226

Post by mmjaa »

tscs37 wrote: post #223
roblabla wrote: post #72

Earlier quoted context omitted.

I don't get why ? It's exactly the same today : you need at least one party to host the data (in this case the archive team). With IPFS however, if more parties wish to host it, it will lighten the load.

There is no incentive to keep data in the network. You can pay pinning services, but what's the point if you're just going to pay someone hosting it? I'd rather have this archived on Siacoin, Storj, Swarm or any other distributed network with actual incentives to keep things around

IPFS+Ethereum = incentive. Please do not be so flippant to reject something until you've grok'ed it sufficiently well enough to argue against it. If you have looked at IPFS+Ethereum and found it wanting, I'd love to know what exactly - because from my perspective this is precisely the kind of technology that delivers your stated requirements.

Re: Archiveteam are backing up SoundCloud

#227

Post by tscs37 »

mmjaa wrote: post #226
tscs37 wrote: post #223

Earlier quoted context omitted.

There is no incentive to keep data in the network. You can pay pinning services, but what's the point if you're just going to pay someone hosting it? I'd rather have this archived on Siacoin, Storj, Swarm or any other distributed network with actual incentives to keep things around

IPFS+Ethereum = incentive. Please do not be so flippant to reject something until you've grok'ed it sufficiently well enough to argue against it. If you have looked at IPFS+Ethereum and found it wanting, I'd love to know what exactly - because from my perspective this is precisely the kind of technology that delivers your stated requirements.

I've definitely "grok'ed" it.

Which is why I find Swarm a better solution. It is literally IPFS+Ethereum with additional support for ENS lookups, deniable storage, redundant storage, etc. This allows for far better privacy and being able to compensate the loss of parts of the file, both features lacking in IPFS itself.

The current swarm testnet performs, as per my experience, better than IPFS in terms of bandwidth and latency.

http://swarm-gateways.net/bzz:/theswarm.eth/

Re: Archiveteam are backing up SoundCloud

#228

Post by kevinmannix »

mdaniel wrote: post #219
kevinmannix wrote: post #208

Shameless plug (has collected a bit of dust): https://github.com/krmannix/downcloud It's a node tool built a few years ago to download the playlists of users through your command line. Might be helpful for a situation where you'd like to back up your own playlists. You'll need to get an API key - no sure how feasible that is at this moment.

No offense, but https://github.com/rg3/youtube-dl is without question the best downloading experience I have ever encountered, and for damn sure doesn't require an API key

Yes, mine is built for SoundCloud, not YouTube or video sites, given the context of the article

Re: Archiveteam are backing up SoundCloud

#229

Post by eatbitseveryday »

__s wrote: post #212
eatbitseveryday wrote: post #210

Earlier quoted context omitted.

Aren't most of the "bits" these days protected by DRM encryption, even in the hardware? I know video is, but audio? I'm always confused when people say they've backed up some website when there are these practical and legal barriers.

If you can play the audio, it isn't encrypted

> If you can play the audio

This forcibly imposes a fixed recording rate, limited to the length of the track itself.

Re: Archiveteam are backing up SoundCloud

#230

Post by mdaniel »

kevinmannix wrote: post #228
mdaniel wrote: post #219

Earlier quoted context omitted.

No offense, but https://github.com/rg3/youtube-dl is without question the best downloading experience I have ever encountered, and for damn sure doesn't require an API key

Yes, mine is built for SoundCloud, not YouTube or video sites, given the context of the article

That leads me to believe you have not used youtube-dl, as it has an unfortunate name but supports an incredible amount of sources: https://github.com/rg3/youtube-dl/tree/master/youtube_dl/ext... including, of course, soundcloud https://github.com/rg3/youtube-dl/blob/master/youtube_dl/ext...
Post reply on HN