And we are live with the MC02!
Thanks for satYatunes to offer his track for the current mix challenge.
Please take note of the new, enhanced and hopefully improved Rules and Guidelines thread:
http://www.kvraudio.com/forum/viewtopic ... 2&t=415154
Yes, it is longer - but it should make things more clear.
Then a word on the provided source material
You will find a sub-folder called "GUIDE" in there. This sub folder contains three stereo WAV tracks that are basically the AUX Returns (send FX) that Satya used for his track. My recommendation is to
basically orient yourself on these FX, but do not use these tracks. Use your own FX, go a bit wild, but keep within the known limits.
What?! 32bit floating point WAV files? Isn't that a bit overkill?
The tracks were originally in 32bit float point precision. This is how Reaper (the host used for this production) was set up. A couple of tracks exceeded the 0dBFS limit (which is no issue with 32bit float), so I pulled them down in volume (maximal signal strength) to -2dBFS. This made bit truncation (or bitrate downsampling) way more easy and definitely less destructive.
I went for a simple "downsampling" method rather than using a Dithering tool for two main reason:
a) it was faster to pull off and
b) the sounds are fairly loud to begin with and the downside of bitrate downsampling/truncation is basically reducing the bitrate resolution, which can result in absolute worst cases in distortion noise.
As part of this Mix Challenge, we will however add more FX to the source material, so to untrained ears, it might not even be an issue and those that are low on ISP bandwidth can access these files simpler.
But we do have a problem with software players and web based players:
We (or better said I) know if SoundCloud can handle 32bit WAV files. I do know for a fact however that not every player can support MP3s at 32bit float. In this case, the playback of 32bit MP3s usually results in noise bursts. FLAC sure can't be encoded with 32bit float or integer either.
So as of this moment, we have three options:
1) If you happen to use the 32bit version, you can render at 24bit and therefore "bit truncate". But this introduces distortion, which is really only an issue on low volume signals
2) Render with a dithering tool on the master out (best case scenario on lower bitrates)
3) provide the file "as is" (48/32float)
Wait, so I do need a dithering tool if I worked at 32bit and want to upload an MP3?
In theory yes. In practical terms, not necessarily if you can live with certain setbacks. Or you have the right CODEC and your player supports these formats. As mentioned before, if you render out in 24bit or even 16bit without a dithering tool, you do heavy bit truncation. And this can result in a heavily distorted sound on low noised signals (especially in 16bit). Most of the time, 24bit is at the acceptance limit, but audiophiles will call you out.
I just checked the 32bit raw tracks with a Bitrate Analyzer to see what's going on. Certain sounds of the currently provided multitrack bundle hover between 4bit to 32bit (so basically 28bit), the full mix results in a readout of 32bit, bass intensive content ranges from 1bit to 26bit, sometimes 28bit. In theory you should be fine. With emphasis on the words "in theory".
In practical terms (if this would be a real live scenario), you do render out at 24bit or higher if you happened to work in 24bit and feel the need to render at "higher bitrates", but if the source files were 32bit to begin with, you can (and should) pretty much stay there and not dither anything. Dithering upon dithering (first after mixing, then on mastering) only introduces more noise.
An info in Dithering and Bit Truncation/Down-sampling can be found here:
http://www.darkroommastering.com/blog/d ... -explained
But can I still encode 32bit MP3 files?
As of this moment, yes this is possible. Again, if you have the right CODEC. Currently this should be possible with the widespread "LAME Project" Encoder, but also with the Fraunhofer ProCodec (though not the Consumer version, this can only render in 16bit!). Though depending on your playback device, your results may vary.
For example - I just pulled a couple of tests with 48/32float files and LameXP (a free windows based multi encoder) from 2013, which happens to bundle the LAME codec v3.96+ as well. But not all hosts and playback devices recognize these files flawlessly. Steinberg Wavelab 8 for example didn't show these files as 32bit but created a temp WAV file with 16bit. This is how Wavelab works. Steinberg Cubase on the other hand listed the files as 32bit through the file import window. AIMP played them back without problems but didn't show any information on the original bit depth, the same with Media Player Classic. I am not too sure on hardware players (here, Noise Bursts are the ordinary), Android Devices, or even SoundCloud.
The MC team will do some tests with the SoundCloud account we will have at our disposal. You can still provide your WAV file how you feel like: 24bit dithered or 32bit float. Same with MP3. We will sort things out on the go.
I mean... this is part of the game - we're all learning and can benefit from our findings.
Mister Fox, you invest a lot of time for this - what would you recommend?
Personally, if I create so called "HD Audio" releases, I dither down to 24bit after I'm done with the final touches (Mastering). This way I can use FLAC or HD AAC (once I get Wavelab 8.5, which has the Fraunhofer ProCodec built in). Files up to 96/24 are known to work in most modern hardware players. Actually, 24bit is also the upper limit on Blu-Ray's in terms of audio streams.
If I don't create HD Audio releases, I still render in 32bit - even if I worked in 24bit. For demo renderings, I use 24bit however, since I'm lazy.
particular topic is not the main focus of this challenge - it's just added bonus information.