I particularly agree with all of his reasons for a desktop client instead of web interface. It's just a better experience for music. And there's an edge use case I hope Spotify will support at some point:
I find a cool remix on Youtube, but it doesn't exist anywhere else. I use a flash downloader to get it, then another program to strip the audio out of it. Now I want to load it into Spotify (Ok so far) and add it to a playlist to share with my friends. So far it seems that sharing music like this (or say that I downloaded from Newgrounds.com) that's not in Spotify's catalog is not enabled. Hope it will be someday.
"Final thought: I'm glad that you guys resisted the temptation to build a web basedapp. I remain a strong believer in the desktop client approach in music for a numberof reasons.
1. Speed/responsiveness of interface, and optimized downloading and streaming
2. Bandwidth savings of P2P architecture
3. Easy integration with hardware devices such as the iPod (ultimately you want tocontrol the interface to the portable devices where you can monetize moreeffectively by charging for download…)
4. There are vast repositories of "grey" content on people's computers across theworld. This content is often forgotten by the labels and publishers. The fact that youhave a client and P2P capability will allow you to someday unlock all of thiscontent…this goes way beyond the master music catalog that is licensed to you bythe labels. A big part of Napster was the joy of discovering various remixes, liverecordings and other obscurities that copyright owners have literally lost track of.
5. While you could have built a "thin" client that runs in the background and powersweb based streaming, why go to all the trouble of building and distributing clientsoftware when you could build the real experience? There is tremendous value incontrolling the client software real estate and it allows for a much snappierexperience."
I'm glad I'm not the only one that uses youtube for music.
I often wonder how much google would save on bandwidth if they let me stream audio only versions of things. The vast majority of the time, I'm not even looking at the visual component of the "video", just listening to the song.
I suppose that this would add computational complexity, as well as additional storage, though. I'm not terribly familiar with the way that youtube stores video.
Can anyone chime in on this? "Extracting" audio from the video containers that youtube uses; how hard is this to do on the server side?
I mentioned this the opposite way around a little while ago (mute the audio in countries where it isn't licensed, rather than blocking the video outright), but the conclusion was generally that the video and audio are muxed together into a single deliverable. The file is almost certainly pre-generated (once for each resolution) to avoid the server-side costs of merging them together for streaming.
I guess in theory you could generate a 'demux mapping' and the client could request byte-ranges corresponding to only one channel, but that seems incredibly complicated, would generate huge requests, and is probably bypassable on the client-side anyway (more of an issue for my idea than yours).
I suspect the reason why they don't is because of legal concerns. It seems like the vast majority of the videos uploaded to youtube are videos that people recorded themselves, whereas the vast majority of mp3s that people share in almost any context are pirated music. There are probably certain small communities where there are plenty of user created mp3s shared, but it doesn't seem to be the case for a sharing platform of any significant size.
Grooveshark manages to get licenses for all these "gray" mp3s after the fact, but I doubt youtube would be able to do so as easily considering their larger market position would be more threatening to the labels.
It wouldn't add computational complexity, or use extra storage. Surely the audio is already stored as an mp3 or some similar format, after all wasn't mp3 invented to be the audio part of video (mpeg) files.
My question comes down to how they're stored. [Obviously] I'm not an expert on video encoding or containers.
FLV is a container, yes? Usually, I'm guessing, MP3 and H.264. H.264 works out well for youtube because they can then also use this on their HTML5 video players.
So are the H.264 blobs and the mp3 blobs stored as discrete files, then packaged when a video is loaded and sent down the tubes? If so, then yeah, obviously, it would be really easy or youtube to serve "audio only"; probably "a few lines of code".
But if the MP3 and H.264 (again h.264 is an assumption) are stored as one [flv] package, they would have to be unpacked before being able to be sent down as their individual components.
Again, this is a shortcoming in my understanding of video containers, so maybe I'm missing the point on this completely. (As in: maybe "unpacking" an FLV is trivial)
Most videos uploaded in the past couple of years would be compressed as MPEG4 (h.264, specifically), but regardless of the video format the audio/video would be muxed into one file. If the video track consists of one still image, the impact (serverside compression, storage, delivery) of the video track would be minimal.
Muchos props to Pandora and their music genome project, glad to see it appears to be succeeding. However, I never really found it a particularly good music discovery service for my own tastes. I get more out of digging around Youtube, subreddits, Newgrounds, and other social music discovery sites. But clearly there's room for multiple approaches to the problem.
And yes, having a phone app that you can sync with your web-based playlists is a good workaround to the native desktop client issue. Just listen on your smartphone instead.
> I find a cool remix on Youtube, but it doesn't exist anywhere else.
Arggghhh, I'm in the same camp as you! I use a variety of music listening services (Spotify, YouTube and HypeM mainly) and I'd love to have one single source to do this all and share with friends. Two major themes pop up here:
1. Any company that could achieve this would effectively create a monopoly status - one which oddly I feel like I would support.
2. Meta data (tags, etc) for audio files is a mess. A side effect of this is the people trying to "game" the system (i.e. "Vocal Superstars presents a song played in the style of Rihanna's song") or reusing song names (i.e. any song that contains the word Love).
Have you tried fizy.com? You can make playlists of songs from grooveshark, youtube (and possibly more, I haven't tried other sites). I'm not involved in any way with fizy.com, just love the site.
Agree with you SkyMarshal on this point. His comments on P2P based software are well put. Its interesting to see that while the push towards web/cloud based aps is strong, how many companies are creating successful client products. It seemed a bit arcane when I first downloaded it, but the functionality and speed far surpasses web based services such as deezer
I find a cool remix on Youtube, but it doesn't exist anywhere else. I use a flash downloader to get it, then another program to strip the audio out of it. Now I want to load it into Spotify (Ok so far) and add it to a playlist to share with my friends. So far it seems that sharing music like this (or say that I downloaded from Newgrounds.com) that's not in Spotify's catalog is not enabled. Hope it will be someday.
"Final thought: I'm glad that you guys resisted the temptation to build a web basedapp. I remain a strong believer in the desktop client approach in music for a numberof reasons.
1. Speed/responsiveness of interface, and optimized downloading and streaming
2. Bandwidth savings of P2P architecture
3. Easy integration with hardware devices such as the iPod (ultimately you want tocontrol the interface to the portable devices where you can monetize moreeffectively by charging for download…)
4. There are vast repositories of "grey" content on people's computers across theworld. This content is often forgotten by the labels and publishers. The fact that youhave a client and P2P capability will allow you to someday unlock all of thiscontent…this goes way beyond the master music catalog that is licensed to you bythe labels. A big part of Napster was the joy of discovering various remixes, liverecordings and other obscurities that copyright owners have literally lost track of.
5. While you could have built a "thin" client that runs in the background and powersweb based streaming, why go to all the trouble of building and distributing clientsoftware when you could build the real experience? There is tremendous value incontrolling the client software real estate and it allows for a much snappierexperience."