Can You Upload Wav Files To Soundcloud

While some streaming services like Amazon Music HD and Tidal are at present offering lossless sound, many others like Spotify, Apple Music, and SoundCloud notwithstanding use lossy sound compression techniques to deliver music. Of those, SoundCloud has always been unique in how easy information technology makes instant uploads for creators.

Perhaps information technology'south due to that very ease that questions like, "Why does my music audio different on SoundCloud?" or "What tin I do to make my music sound amend on SoundCloud?" seem to come up more often than they practice for other streaming services.

Despite SoundCloud introducing a new "mastering" feature to optimize streaming playback, knowing what actually happens to your audio during streaming and mastering is cardinal to agreement how to produce a track with the highest possible sound quality for streaming. And so let's take a expect at why those sonic changes occur, and what we can exercise to minimize them.

In this piece you'll larn:

How to optimize your songs for streaming on SoundCloud and other compressed sound formats
What you can and tin can't control in the process

The bottom line

To get to the bottom of this, I prepared 40 masters of a single song—twenty at 44.i kHz and 20 at 48 kHz—and uploaded them all to SoundCloud. For each sample rate, I methodically varied the parameters of peak level, crest cistron, frequency-specific width, and total width. I then played them all back off SoundCloud, recording the output bitstream pre-conversion—once more at 44.i kHz and 48 kHz—for analysis and comparison against the originals. This yielded a whopping 80 versions of the song!

twenty uploaded and recorded at 44.1 kHz
20 uploaded at 48 kHz and recorded at 44.1 kHz
20 uploaded at 44.1 kHz and recorded at 48 kHz
20 uploaded and recorded at 48 kHz

Testing twoscore versions of a song

After level matching them all for a off-white comparison, I got to work listening and measuring to determine which factors played the biggest function in preserving—or degrading—sound quality during format conversion and streaming playback. At the end of the solar day the parameter which made the biggest impact was: width! Not only that, but all the other variables had little to no impact (caveats ahead).

To sympathise why this is, how you tin can potentially take advantage of it, and why you might not want to worry virtually it at all, read on!

Manipulating width for a "amend" encode

I should qualify what I mean by "better." Really, what we're talking well-nigh is an encode which is perceptually closer to the source. Nevertheless, the steps we're taking to become there involve making some sacrifices to the source. So while the encode and the source may audio more than akin, the cumulative deviation between the encode, the source, and what you were originally trying to achieve may still be adequately noticeable.

That qualifier aside, here are a few things y'all can do to minimize the differences betwixt the source and the encode:

Narrow the high-end

Using a tool like the Imager in Ozone ix, attempt narrowing frequencies above about 8 kHz. I can't requite you a precise corporeality, as it will very much depend on the amount of width that you had in that range to begin with. Try soloing that band and reducing the width until it occupies nearly half of the stereo field betwixt your speakers. This will assistance reduce some of the loftier-frequency washiness that is so common with low-bitrate lossy codecs.

Narrow mid and low frequencies

If yous want, and your master can handle it, try narrowing the mid and depression bands too. Try setting the mid ring to nearly i–eight kHz, and the low band below 1 kHz. You lot could even split this into two ranges: 400–1000 Hz and beneath 400 Hz. You lot'll likely want to leave the mid—and low-mid if you're using it—bands adequately close to their original width, however, you may exist able to get abroad with narrowing lower frequencies a fleck more. Any little bit helps.

Utilize a mono main

This is absolutely an extreme solution, but if you tin justify it, a mono source volition give you the "best" encode—over again, meaning perceptually closest to the source, albeit now in mono. This is considering you're essentially asking the encoder to practise half as much work past encoding a single channel. In plough, this means the encoder tin allocate it'due south entire bandwidth to that one channel, rather than having to divide it betwixt two channels.

The reasons width plays such a critical office in encoder functioning are hugely complex, but tin can be summarized every bit follows: near lossy encoders like AAC, MP3, and Opus utilise a technique known as joint stereo encoding. This means that rather than encoding both left and correct channels independently, they utilize multiple techniques such equally mid/side and intensity-stereo coding to optimize bandwidth allocation to where information technology will exist most noticeable—frequently the center of the stereo prototype.

The end result is that ultra-wide stereo signals oftentimes endure from quality degradation more noticeably than do narrower ones. Additionally, high frequencies require more bandwidth to encode. Thus, by reducing the width of high frequencies, not simply do you free up some bandwidth for the encoder, assuasive it to allocate its bits more than efficiently, but you as well foreclose some of the more noticeable, warbly, washy baloney from showing up in the encode.

A smashing way to experiment with the effects of these changes in real-time is past using the Codec Preview in Ozone 9 Advanced. Endeavour using MP3 at 128 kbps or AAC at 256 kbps—2 of the common codecs used by SoundCloud depending on the playback platform and subscription level—and tweaking Imager parameters. You tin even utilise the "Solo Artifacts" office to hear how changes in width bear on the underlying distortion added by the codec.

Codec Preview in Ozone 9

All the other bits

I would exist remiss if I didn't accost things like tiptop level, crest-factor, and file format for upload, and then let's talk most those at least a little.

In all my recent tests, acme level did not have a noticeable affect on encoder performance—at least non directly. By this, I mean that then long as there wasn't any clipping, the encoder performance between versions with unlike amounts of peak headroom was identical.

Still, because lower bitrates—such equally those often used by SoundCloud—can cause peak level overshoot of a decibel or more than, it'south good exercise to fix the ceiling of your limiter to -one or -1.5 dB and utilise a True Pinnacle limiter such as the Ozone Maximizer. This helps prevent clipping on playback, specially through cheaper consumer devices.

The story with crest factor is largely the same. While it doesn't have a straight, dramatic impact on encoder functioning, a lower crest gene volition oftentimes effect in higher top level overshoot—something which ultimately often results in DAC clipping and distortion. This has the slightly ironic effect of requiring boosted peak headroom—or a lower limiter ceiling—the higher you push your average level, something which can quickly plow into a losing battle.

This is another surface area where Codec Preview in Ozone ix Advanced can be enormously helpful. By turning on Detect "Truthful Peaks" in the I/O options and listening through the MP3 128 kbps codec, you can fine-melody the Maximizer threshold and ceiling to achieve an optimal level while fugitive mail service encode clipping.

Checking post-encode peak headroom in Ozone nine

As for upload format, the official recommendation from SoundCloud is a 16-flake, 48 kHz WAV file. This reason for this is that of the several codecs used, the bulk of them are set up to take in a 48 kHz file, so this minimizes the corporeality of sample rate conversion that volition take identify.

That said, sample rate conversion has become extremely transparent, and in my tests neither the upload nor playback sample rates had an observable consequence on encoder performance or playback quality.

The 1 caveat here is that if you enable downloads on SoundCloud, the file you lot upload is the one your fans get when they download. Thus, if yous want them to receive a 320kbps MP3, that'due south what you'll demand to upload. However, this results in transcoding from i lossy format to another, which never sounds particularly good.

In brusque, if you want the best streaming quality possible, upload a sixteen-scrap WAV at 44.ane or 48 kHz. If, on the other hand, you lot want to enable downloads, upload the file y'all desire your fans to receive, only know that if information technology'southward a lossy file, streaming quality will suffer. Since these days downloading a local copy is probably not as common equally it one time was, this may be a moot point.

Decision

To wrap upwardly I want to consider a few reasons why maybe you shouldn't worry also much about all the factors nosotros've merely discussed.

First and foremost, SoundCloud may well update the codecs they employ in the hereafter just as they have in the past. When that happens they volition re-encode all uploaded music to take reward of the new codec(s). It's for this very reason that they themselves urge creators not to try to optimize files too much for a specific codec.

Second, while you lot tin control the width, sample charge per unit, etc. of the file you upload, you can't control how your fans will listen to it. Of course, this is truthful of the vast bulk of playback mediums. It bears repeating here though considering even on SoundCloud alone, the playback experience can vary depending on subscription level and playback device. Consider carefully whether it'due south worth sacrificing some of the width and spaciousness of your track but for the lowest common denominator.

Hopefully, this has armed you not only with some of the tools to improve encoder performance when uploading to SoundCloud but also the wisdom to know when, when not, and how strongly to wield them. Good luck, and happy mastering!