Yes, I got the impression from some of the Steinberg WL 8.5 release notes that somebody at Steinberg is assuming or suggesting that you can submit AAC directly for sale on iTunes. Every iTunes aggregator I’ve seen requires 16-bit/44.1k WAV files and AAC conversion happens from there. I hope soon that any user can submit “Mastered For iTunes” compatible files at 24-bit and native sample rate, but this requires precise analyzation of your mastered WAV files with the exact encoder used by Apple iTunes Store. I think most aggregators are still at 16-bit/44.1k so they don’t have to deal with getting multiple formats from clients because maybe iTunes can do 24-bit, but Spotify and Amazon may still be at 16-bit. There are too many variables to open up to 24-bit, most clients do not even understand the difference which doesn’t help.
Regarding new AAC support, I think it should be clarified if Steinberg is talking about making AAC files to be more compatible with your personal iTunes library and other Apple products, or if they are speaking of distributing your songs for sale on iTunes, the latter seems to be misleading.
I personally don’t bother making AAC files, I either do WAV for professional distribution and production, or mp3 for clients that request mp3s for personal and promo use. There are some download code services that request mp3 files as they simply host your files and don’t do any conversion because there is no standard there. They host what you give them.
I do think that for Wavelab 9, some kind of automatic batch analyzer would be great with either a suggested amount to lower your limiter ceiling to avoid overs after iTunes Store AAC conversion, or an automatic setting to avoid these overs. However, it seems that you would have to use the Sonnox Pro-Codec which contains the exact MFiT codec to be sure of the final results for MFiT compatibility. The encoder checker that Apple provides is only AU so that wouldn’t work in Wavelab without a wrapper which is not ideal, and maybe not trustworthy.
Thanks for the information Jperkinski. I didn’t realize that Steinberg believed that AAC, MP3, or Ogg were created by the mastering studio for release. In all cases, they’re not. The mastering studio supplies wav in all cases and the retailers or record label create the lossy files themselves:
Apple makes their AAC using the Apple AAC codec (iTunes+ 256) from mastering studio:
24 bit wav for MFiT (level reduced).
16 bit DDP for standard iTunes (not level reduced).
Amazon and Google make their MP3s from mastering studio:
16 bit DDP (not level reduced).
Spotify makes their Ogg from mastering studio:
16 bit DDP (not level reduced).
The only thing that gets level reduced and clip protected specifically by the mastering studio is the MFiT, by the mastering studio supplying a level reduced 24 bit wav. All the others are encoded from the level of the DDP, and therefore are subject to clip and ISP that would be generated at those levels. If you want all your MP3 and Ogg and Standard iTunes AAC to be without clip or ISP you’re going to have to reduce or check to confirm your DDP level after lossy encodes.
It’s true there could be confusion. First of all, “iTunes” is one thing (software), and “iTunes store” is another.
But I don’t think Steinberg says somewhere that AAC files can be uploaded to the iTunes store.
AAC is the original audio format supported by iTunes.
In the same time, the preset iTunes and iTunes+ in WaveLab correspond to standard AAC formats used on the iTunes store.
Sorry, didn’t mean to put words in your mouth. I don’t think they should call the Fraunhofer “itunes +” although it’s only named that in the preset. Either way (ingestion or playback), the Apple codec should be available, and that could rightfully be called “iTunes compatible” because it’s exactly what iTunes uses. There isn’t an “official iTunes MFiT” codec, different from the one used by the ordinary user in iTunes: It’s the Apple AAC codec built in to the Mac. And the one on Windows is so close as to be identical as far as clip and ISP levels, and sound. Apple calls that codec with those settings “iTunes +” on both platforms, so they’re effectively interchangable and to my mind both perfectly usable for MFiT (if or when Apple ok’s that). So I still believe the Apple codec should be added to Wavelab.
The 'round trip AAC" AU audition plugin with the wrapper would only be needed if the Encoder Checker didn’t have audition, but it does, so that’s not an issue (in my opinion). The Apple AAC codec itself is and should be usable in Wavelab on both platforms. If Apple says it’s close enough to call it the same thing (iTunes+) in Mac iTunes and Windows iTunes, it’s close enough.
I’ve noticed that when loud non-MFiT iTunes store files are analyzed in Wavelab 8.5 Global Analysis, the digital peak is -0.0003, and they have no one-sample clips on the error tab. Those same files show digital peak 0.0000 and many one-sample clips in Wavelab 8.03 (as they would show in Apple AFCLIP). I ‘guess’ this is because 8.5 uses the Fraunhofer AAC codec to decode, and 8.03 uses the Apple AAC codec to decode. Is that correct?
Ideally, to me, an Encoder Checker would have 2 purposes, depending on the client: (1) for label clients, to mirror as closely as possible the codecs that the record labels or retailers are going to use to make their lossy files from the mastering studio’s DDP or WAV, or (2) to include “better” codecs (like the Fraunhofer) for those who are able to utilize them for self sales.
That’s why I think the Apple codec should be added to the encoder checker and Global Analysis. Because that’s what Apple uses to make the AACs in the iTunes store, making them from the mastering WAV or DDP. I admit the codec request is picky, especially considering they’re lossy files, but Apple is picky.
Someday I’d like to analyze what codec/settings all of the retailers/streamers are using for encode/decode. That would be more exact information to add to an encoder checker, and since Wavelab includes Ogg Vorbis, could include the Spotify stream.
I second Bob’s request; I do a TON of MfiT masters, in fact it’s my default workflow. While I can repeatably deliver files in-spec with 8.03 without the Apple AU’s in-line, relying on True Peak in WL, I’d really like this new feature to eliminate the need to run Apple’s droplets and AUs for checking the files. So, please consider adding Apple’s codec to the kit.
I realize licensing is probably the block here, so I might suggest a direct request with iTunes/Audio folks at Apple to see if an arrangement can be made to waive fees in support of their MfiT initiative. They make more money from good sounding audio than bad, and have invested a lot in this. They give those tools away, not to sell macs but to sell more in the iTunes Music Store. So the request seems reasonable.
Are there even fees? The entire ‘official’ MFiT AAC encode/decode can be done from the command line in any Mac Terminal, using the settings and commands given in the Apple MFiT PDF. (Not just the free Apple MFiT droplet (which does exactly the same thing)). And wouldn’t there be a similar usage on Windows? Not EXACTLY the same result AAC, but EXTREMELY close. Much closer than the Fraunhofer.
Only thing to keep in mind is they’re using the Apple SRC, but that’s part of the command.
Well there wouldn’t be fees if you’re using Apple’s tools on a mac but… those are AU only (which WL and PCs can’t run).
Apple’s a hardware company first. They’ve not made things easy for competing standards (be they VST or AAX). The codecs are built into iTunes of course, but a)they’re not the same ones, and b)they really only make PC iTunes to sell iPads and iPhones. So lack of license fees in these contexts are understandable. I think Quicktime Pro and it’s descendants are officially unsupported now, or close to it - those tools brought some of the kit to PC users in the past.
I dunno, honestly. I do know PG’s not using their codec’s now though, for whatever reason, and Sonnox does. I guess a plug-bridge from VST-AU might work for mac users with Apple’s existing tools in terms of legality and function.
The AU plugin is not needed IMO because it’s just an audition thing and Wavelab EC has audition. I was just talking about the AAC encode/decode. I’ve tested the Windows iTunes “iTunes +” encoder settings against the Mac (MFiT and iTunes). They’re extremely close. Which I would expect, because if you make an AAC in Mac iTunes using the “iTunes +” setting and one in Windows iTunes using the “iTunes +” setting you would expect to get comparable files. And they are. Extremely close. Close enough for Apple to call them exactly the same thing.
The Mac iTunes “iTunes +” encode matches the MFiT official droplet encode exactly. It didn’t used to, but they changed the settings in iTunes to use the “mastering” parameter settings. Therefore the Windows “iTunes +” is extremely close to the official Mac MFiT.
I just found out that the MP3s being sold on Amazon and Google Music are using the LAME encoder, so I was glad to find in Wavelab 8.5.10 that the encoder checker has added LAME. Amazon uses ~270 VBR, Google uses 320 CBR, for the same tracks, so it appears to me that the retailers themselves are probably making the lossy files, not even the record labels. I wasn’t sure. The other services MP3s? Probably LAME. I don’t know yet.
One question, when you select LAME in the encoder checker, is it using LAME for both encode and decode, or just encode?
I found a strangeness when encoding a file to LAME VBR HQ_HQ in Wavelab. The resulting file appears as 128k CBR in Foobar and iTunes. I tried doing the same thing with the LAME encoder in Foobar (“MP3 VBR V0”), and it appears correctly in Foobar and iTunes, like the Amazon VBR file does.
One or two things I’d like to see added to the encoder checker is level meters on the EC itself (even small ones, just so it’s more like the Apple AU plug), rather than looking “over there” to see the Master Section meters. Also phase reverse so you can hear the difference you’re seeing on the FFT. I think the FFT is great.
Oh, and of course the Apple codec. I think any encoder checker that doesn’t include the real targets that are going to be used (like the LAME and the Apple) is short-sighted, or just unaware that the mastering studio doesn’t make the commercial lossy files.
PG, I tried this again and get the same thing. Wavelab LAME VBR Highest Quality are reported as 128k CBR in iTunes and Foobar. Foobar LAME VBR and Amazon LAME VBR are reported correctly, as VBR. Any idea what this might be?
Certain VBR encoders add an extra header at the file start. WaveLab does not. I think this is the explanation.
This being said, I have verified in the lame vbr file encoded by WaveLab is really vbr.
Thanks for the explanation PG. It’s a minor point, but is there a reason why you don’t add a header? The Fraunhofer also doesn’t appear as VBR, it appears as 192 CBR. And the codec and version (Fraunhofer or LAME) don’t appear in other programs as they do with alot of MP3 files. The only reason I would ask for a header is because I don’t think I’d make a LAME VBR at all to send to someone, but only because it would appear as 128k CBR on their end.