[ans?] MySpace (& Soundcloud, etc, etc...) quality check

Hi Dave, I was just thinking about emailing you. What do you use to host your stuff, where you showed me?

To my ears, Soundcloud sounded better with a WAV. I can’t hear much of a difference with 16- or 24-bit but the FLACs both sounded - where’s that great word gone…wabbley! I’ve got all four versions up there at the mo if you fancy a listen (link in sig), I’d be interested in your opinion if you’ve got time, because having just had another listen, I’m not sure any more…

As far as SoundCloud goes I’ve always uploaded 16 44.1 wav files and let them do the compression/conversion. I haven’t noticed anything obviously annoying with the result so that’s what I continue to do. I haven’t tried any other sites to compare quality. Then again, my songs probably aren’t the best quality to begin with :blush: .

In case you want to check out some samples …

http://soundcloud.com/scab-pickens

You should be able to download the 16 44.1 files to see if you can notice much of a difference from the stream.

Unless I’m way off, the file size that you upload to these sites is irrelevant – they all stream at 128kps. This is why I have been using the soundclick VIP account ($9.95/mo) which allows streaming at a 320kps. Another option is to purchase your own domain and webspace and stream from that (it’s actually fairly cheap nowadays)

Actually, there IS yet another option – make your listeners download the tune from these sites in the better file format. Whenever I encounter this requirement, however, I skip it and move on

I think you may be right about the 128k streaming in general - makes sense, after all - so it’s just a case of working out what the encoding works best on. Earlier there was a hint that there might be technical parameters - engineering, not format - you need to keep within in order to make the best of the encoding algorithms so maybe this ought to be the next line of enquiry.

Yes Doug you are correct. However, if you upload a 128kps file to soundcloud, for example, it then goes through their mp3 encoder again! :open_mouth: :unamused: I am pretty sure bandcamp does the same. Soundclick only encodes the files again if you don’t upload the correct type or bit rate for the corresponding account type.

The streaming bitrate is fixed to prevent people from consuming too much bandwidth by selecting the 320kps option. It’s independent (though may be tightly bound to) of the filesize when it’s stored on the site.

What may be happening - purely speculatory though - is that they are converting the file to a fixed bps value upon upload. If you’re uploading a lossy format then you have a double conversion going on: one to decompress the audio data from the format you’re uploading in and then another to re-compress it in whatever format they’re using (probably MP3).

If the site isn’t smart enough to check if your format is already the same as what they require then you also have issues with the quality of the codec. In other words, 128kps MP3 is not the same (obviously) so you may have encoded using codec A to 128kps then they use codec B to decode into PCM so that they can re-encode it using codec B into 128kps.

Every step introduces errors. This is why Bandcamp’s requirement to only use lossless formats to upload is a sound decision, pun absolutely intended. :smiley: :smiley: :smiley:

I highly doubt Bandcamp encodes the file into a lossy format. Given their requirement that you upload a lossless format and their “value-add” that users can request a sound be in any number of formats it would be against every ounce of logic to shoot themselves in the foot by storing the data in a lossy format.

Edit: corrected “upload a lossy” to “upload a lossless” which is what I originally meant.

I’ve just been having a read of the mp3 Wiki page (http://en.wikipedia.org/wiki/MP3) and associated links and two subjects, hopefully relevant, drew my attention:

  1. Masking leading to compression artefacts - this would be an engineering issue, no? http://en.wikipedia.org/wiki/MP3#Audio_quality and http://en.wikipedia.org/wiki/MP3#Design_limitations

[Edit:] There is also a reference in there to how badly sharp attacks are handled, hence the acoustic guitar problem, I suppose.

  1. Encoder choice:

It must be kept in mind that an encoder that is proficient at encoding at higher bit rates (such as LAME) is not necessarily as good at lower bit rates. > http://en.wikipedia.org/wiki/MP3#Encoding_audio

So the general advice here seems to be that choosing a site, like Soundcloud or Bandcamp where you can or have to upload lossless formats would negate this, leaving it all down to the mixing engineer…

Oh, the learning curve…

Sorry, I should have been clearer. Bandcamp streams at 128kbps so the better quality of file you upload the better the streaming quality, at least from my experience.

According to their FAQ they demand quite the contrary: http://bandcamp.com/faq#aiffwavuploadrequirement

I always upload 16bit .WAV but unfortunately the quality of the streams have still been hugely variable. :confused:

You’re Bandcamp/Soundclick, right? Do you find that you get variable quality even within the same site? And as regards 16-bit WAV, I could swear that they sound better on Soundcloud than 24-bit.

my brothers…

Regardless of whatever file format you upload to ANY of these sites, I will bet my left testicle that they STREAM your song at 128kps. NOBODY anywhere streams .wav files – NOBODY! It is ENTIRELY a bandwidth issue. (They make a companion 128kps file of your uploaded tune strictly for this purpose – most of the time this takes place behind the scenes)

I am quite sure of this. The reason I quit using Bandcamp is because my tunes were sounding like CRAP when they were streamed – usually all warbly, etc. I haven’t had this problem using the VIP option at soundclick, which allows 320kps streams

also

I know there’s a lot of myth, BS, and hyperbole that gets spread around on issues like this, but really, I think it’s quite easy to discern the quality difference between a 128kps file and almost all other file types. On the same note, I personally can’t ever tell the difference between a .wav file and its AAC256 or 320kps mp3 versions, as some folks claim

Bro, you can keep your tackle intact :wink: , I think we’ve established that (for freely available sites, anyway). The question is really: what is the best kind of file to submit to what site given that this is the case? The encoding at their various ends doesn’t seem to make the same job of all file formats.

Of course, there is always the other question: how much of the warbling problem that seems to be widely experienced is down to - not to be too blunt about it - poor engineering. Not all of it, from what I read - there are limitations to what the codec can do (http://en.wikipedia.org/wiki/MP3 and links from) - but almost certainly some is due to masking, wouldn’t people agree?

As OP, I’d like to take the opportunity to thank all contributors for a most enlightening journey. The next stage of the discussion may be to establish the “best” way of engineering tracks that are intended for online streaming. Hopefully this will not be a futile effort, although I don’t expect there to be any hard and fast rules, if any at all.

Cheers, keep the thoughts coming…

That’s what I meant. I was still braindead when I wrote that. :laughing:

Thanks for catching it.

Got some significant info to add to this, regarding encoders in general. So, putting aside the question of what took me so long to try it, here it is.

I have never used the Cubase Export mp3 (Fraunhofer) encoding because it requires, eventually, a paid licence, which I am too stingy to fork out for. However, I had a few goes left so decided to give it a try on the 24-bit WAV I have been using as a basis for comparison throughout this. I exported at 128k and the result was clean as you like.

I then exported from Audacity, which uses Lame, at 128k. Result - hideous amounts of warble! I checked the 320k export I’d done earlier and that was pretty poor too.

I then checked the Audacity website to see if there was an update and there was! So I re-ran the experiment using the new version of Audacity (2.0, but shouldn’t be relevant as the encoder is a separate thing) with the updated Lame encoder. Result: much, much better! Couldn’t hear much of a difference, if any, from the Fh version.

To summarise:
Fraunhofer @128k - fine (from 24-bit WAV using Cubase)
Lame 3.98.2 @128k - hideous (from 24-bit WAV using Audacity)
Lame 3.99.3 @128k - fine (from 24-bit WAV using Audacity)

So, I wonder if the reason MySpace (and other sites, from what people have reported) sound so appalling is that they’re still using an old version of the free Lame encoder and need to be told to get on with upgrading it?

It may be for some but for me, I don’t believe so. Just yesterday I uploaded a 16bit WAV to both Bandcamp and Soudcloud. The difference in their streams is quite apparent. Niether are great, but Bandcamp is, well…dreadful! :confused:

Soundcloud is the best (free) stream I’ve come across yet so, seeing as I’ve been uploading the same files as I have been elsewhere, the only conclusion that seems to fit is that other sites are using inferior transcoders.

The tests I ran were on my system here, through my desktop player, not via any site. Using Lame 3.98.2 @128k here gave the same horrible sound as you get on MySpace, whatever format I upload. But using 3.99.3 was such an improvement that it seemd a reasonable assumption that MyS (and Bandcamp, perhaps) are using the old version. I’m assuming they’re using Lame as it’s free.

If this is the case, the only way it’s going to change is by pointing this out to the sites, which I realise is hopelessly naive but unless you try…