Thought this might be interesting, and did not find it mentioned in other posts:
http://arstechnica.com/apple/news/2012/04/...-the-test.ars/1 (http://arstechnica.com/apple/news/2012/04/does-mastered-for-itunes-matter-to-music-ars-puts-it-to-the-test.ars/1)
Funny that you were to mention this. I was just about to post this...
It's interesting how Ars is making claims that are the result of sighted, casual testing.
To make sure we weren't hearing things, though, we repeated Shepard's null test experiment. As with Shepard's test, comparing the CD master to a straight iTunes rip produced quite a bit of warbled noise and static. But the null test done with our own specially mastered version was very nearly silent.
They messed that up then. Since when did a null test of lossy audio deliver something "very nearly silent".
Some other factual errors, and silly statements, in the article. Some truth too though.
Cheers,
David.
Comments >> article.
The article illustrates nicely that the underlying motivation for "Mastered for iTunes" is not generally understood. The comment by
itsbenaltogether (http://arstechnica.com/apple/news/2012/04/does-mastered-for-itunes-matter-to-music-ars-puts-it-to-the-test.ars?comments=1&start=40#comment-22808120) sums up the central points pretty well:
[...] All this article is saying is that it is possible to master a record in a way that reduces artifacts due to AAC compression. This doesn't sound that outrageous to me and the advice Apple is giving people isn't exactly rocket science either. If AAC compression can cause clipping, it's a no brainer to reduce the levels before compression. To do this most effectively, it helps to have the best dynamic range signal available. This all sounds straightforward to me.
Add the point that heavy dynamic compression tends to introduce more high-frequency content which, being harder to encode, either gives higher data rates or reduces overall quality, and you've got the gist. Not rocket science to him or to me or anyone else with
some kind of signal processing background, but to the average mastering engineer it apparently is. This article could have done something about this, but as-is it's just yet another missed opportunity.
...
[...] If AAC compression can cause clipping, it's a no brainer to reduce the levels before compression. To do this most effectively, it helps to have the best dynamic range signal available. This all sounds straightforward to me.
...
Would it not be simple to automate this in the encoder implementation?
Add the point that heavy dynamic compression tends to introduce more high-frequency content which, being harder to encode, either gives higher data rates or reduces overall quality, and you've got the gist.
What would the consequence be of coding a highly-dynamic waveform, and transmitting the compression parameters as a small meta-data field, for doing heavy compression after decoder instead?
-k
What would the consequence be of coding a highly-dynamic waveform, and transmitting the compression parameters as a small meta-data field, for doing heavy compression after decoder instead?
-k
You could hack that data and skip or reduce the compression.
I have no inside knowledge of how these guys operate, but I suspect the parameters are not always constant through a whole track, so that field may have to be in each frame or otherwise time coded rather than just one time up front.
Add the point that heavy dynamic compression tends to introduce more high-frequency content which, being harder to encode, either gives higher data rates or reduces overall quality, and you've got the gist.
I wonder what JJ thinks about the assertion that AAC chokes on high frequency content. AAC is his baby, I thought he did better work than that! ;-)
OTOH if they are talking about heavily bit-reduced encoding, I can see where reducing bandwidth can help. I play that card with the spoken-word MP3s that I post - use the lowest possible sample rate so that no bandwidth goes into sibilant sounds that don't need to be heard, and may even be detrimental to listening pleasure and articulation.
You could hack that data and skip or reduce the compression.
True. Why should an artist or mastering studio fear that their paying customers found ways to reduce the compression applied to their tracks, any more than how they are able to change the linear frequency response by applying eq?
I have no inside knowledge of how these guys operate, but I suspect the parameters are not always constant through a whole track, so that field may have to be in each frame or otherwise time coded rather than just one time up front.
Sure. But even if one allowed 3-5 bands of time-variant gains, I would suspect that they could be easily compressed (signal-dependant and correlated in time/frequency).
If they want complete flexibility (to use e.g. 1960s tube compressors), I could live with Apple having access to both pre-processed and post-processed versions, using some fancy compare/encode algorithm to transmit only clean source + mastering-process information.
-k
Null tests with lossy compession, here we go again!
Yet another article where failure to employ proper double-blind comparison techniques has resulted in conclusions that are completely untrustworthy.
Apple's tool set should have included an ABX tool.
OTOH if they are talking about heavily bit-reduced encoding, I can see where reducing bandwidth can help.
They are talking about iTunes downloads, so no, they are not talking about heavily bit-reduced encoding; not to the extent that you're talking about, at least.
This comment (http://arstechnica.com/apple/news/2012/04/does-mastered-for-itunes-matter-to-music-ars-puts-it-to-the-test.ars?comments=1#comment-22807873) perfectly sums up the problem at hand. As long as Masterdisk et. al. are unwilling to understand lossy encoding/digital audio processing and revise their mastering techniques nothing will change for the better.
I liked how the author quoted xiphmont's article regarding the 24/96 push, at least some voice of reason from the tech press.
I would be interested to know the actual problem solved by "Mastered for iTunes". To me it seems this hasn't been well understood by those using the process.
The gist of Apple's PDF (http://images.apple.com/itunes/mastered-for-itunes/docs/mastered_for_itunes.pdf) on the subject seems to be:
- Give us your hi-res masters and let us do the SRC to 44.1kHz/32 bit float. This way you can not mess up the SRC (introducing aliasing and clipping) and no additional (dither) noise is added, making the files easier to encode.
- Consider making your tracks less loud, since tracks which are too loud may introduce clipping on playback. They offer oversampling as one source of clipping and conveniently avoid talking about decoder side clipping.
In other words, some mastering engineers (maybe even Rick Rubin?) were sending Apple badly resampled and clipped material, which when put through the codec resulted in even more clipping. I believe that in the end, this may (in some cases) actually result in AAC files sounding worse than the original hi-res master. But apart from those two factors, the PDF does not indicate any detrimental effects of the encoding process on the perceived sound in any way. In fact they say (emphasis mine):
By using this highly accurate file directly from our SRC and taking advantage of its clean signal, our encoder can deliver the final product exactly as the artist and sound engineers intended it to sound.
Whatever you decide—exquisitely overdriven and loud, or exquisitely nuanced and tasteful—we will be sure to encode it and reproduce it accurately. We only ask that you avoid clipping the signal.
The people over at Apple must be pulling their hair when reading about how their toolchain is being put to use.
Master for itunes?
Well,there will be more bad mastered projects, I'm afraid. But it may be better since there is no any considerations in old school since the iTunes is the new one.
Pretty much the whole "story" behind this is Apple telling people to avoid clipping.
And from that, Arstechnica goes into a 3 page article looking for some magic sound improvement in an uninformed audiofool fashion. But oh well, at least the first page is decent, they included a few relevant sources..
Kudos to db1989 for anticipating the quality of the Rush remasters (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=93628&view=findpost&p=787988).
In other words, some mastering engineers [..] were sending Apple badly resampled and clipped material, ...
I would expect them to have been using the CD or at least the same master and that says something about the state of (a lot of) mastering today.
I wonder what JJ thinks about the assertion that AAC chokes on high frequency content. AAC is his baby, I thought he did better work than that! ;-)
I didn't mean "choke", but rather bitrate needed for a given quality. Anyone who's watched bitrate display during playback has probably noticed how bitrates go up as more highs are involved, regardless of whether it's MP3 VBR or AAC LC.
Of the few CDs that I own in both original '80s and (last decade) remastered editions, the latter consistently show a higher data rate when using the same MP3 encoder and VBR quality setting (all between -V 4 and -V 6, so SFB21 shouldn't play a role).
Cocteau Twins - Heaven Or Las Vegas, LAME 3.98.4, -V 4: 152 kbps - 156 kbps
(A surprisingly small difference considering that the remaster is pretty much SMASHED.)
Cocteau Twins - Head Over Heels, LAME 3.98.4, -V 4: 156 kbps - 162 kbps
I also have both versions of Peter Gabriel's eponymous 4th, but sadly one is in -V 4 and the other in -V 6 right now and the FLACs and converter setup are on my old, slow computer still. It also seems I never bothered to transcode the infamous Brothers in Arms.
Apple's tool set should have included an ABX tool.
It does. It includes the Audio Units plugin: AURoundTripAAC which includes an ABX test section.