Feature request - ability to decode Lossy files to 32 Bit Float for purposes of analysis and metering. I just noticed Apple Afclip apparently does this when “directly” analyzing AAC files. It makes a difference in the number of Clip levels reported.
As soon as you open an encoded file in WaveLab, it is decoded in a 32 bit float (temporary file). WaveLab only works on that temporary file.
Yes but lossy files are always decoded to 16 bit initially by Wavelab, pinning those existing clip levels at 0db forever, and thereby making number of clip level analysis very different than the 32f analysis (with non-ISP levels over 0db) as seen by Apple on masters they receive from mastering for MFiT iTunes+. This could be corrected by allowing lossy to 32 bit float decode in Wavelab. Then the numbers would match Apple’s and we could know what we’re doing, with precision. It’s only a first step, because IMO the whole Apple MFiT chain should be called by the mastering program at some point so as to make analysis identical, but this would be a first step. On the Mac, the whole MFiT roundtrip chain (including Apple SRC) is all there and all written in open AppleScript already in the MFiT Tools. (Not the roundtrip audition plugin, that wouldn’t be needed for such an offline process. I mean the AppleScript in the other tools, the AppleScript Droplets, and the Afclip info in the PDF).
Afclip “direct” Apple MFiT AAC analysis (result as seen and judged by Apple):
total clipped samples Left on-sample: 68 inter-sample: 184
total clipped samples Right on-sample: 49 inter-sample: 154
Afclip (Apple MFiT AAC to 32f Wav decode by MFiT AppleScript) Wav analysis: (same result as previous)
total clipped samples Left on-sample: 68 inter-sample: 184
total clipped samples Right on-sample: 49 inter-sample: 154
Afclip (Apple MFiT AAC to 16bit Wav decode by MFiT AppleScript) Wav analysis:
total clipped samples Left on-sample: 0 inter-sample: 127
total clipped samples Right on-sample: 0 inter-sample: 97
PINNED SAMPLE RUNS:
SECONDS SAMPLE CHAN VALUE DECIBELS
61.847052 2727455.00 1 -1.000000 0.000000
69.928163 3083832.00 2 -1.000000 0.000000
119.502449 5270058.00 2 -1.000000 0.000000
127.458345 5620913.00 1 -1.000000 0.000000
141.818730 6254206.00 1 -1.000000 0.000000
148.276667 6539001.00 1 -1.000000 0.000000
total pinned samples Left 27
total pinned samples Right 17
Afclip (Apple MFiT AAC to 16bit Wav decode by Wavelab Fraunhofer) Wav analysis:
total clipped samples Left on-sample: 0 inter-sample: 125
total clipped samples Right on-sample: 0 inter-sample: 96
PINNED SAMPLE RUNS:
SECONDS SAMPLE CHAN VALUE DECIBELS
61.847052 2727455.00 1 -1.000000 0.000000
69.928163 3083832.00 2 -1.000000 0.000000
119.502449 5270058.00 2 -1.000000 0.000000
127.458345 5620913.00 1 -1.000000 0.000000
141.818730 6254206.00 1 -1.000000 0.000000
148.276667 6539001.00 1 -1.000000 0.000000
total pinned samples Left 27
total pinned samples Right 17
The Wavelab pinned 27 and 17 don’t come close to the Apple 68 and 49, and the ISP are quite different as well. Wavelab decode would be (edit:) (nearly) identical to the Apple AAC analysis if it could decode lossy to 32 bit float.
I don’t think the problem would be solved by your suggestion. The finding of true peaks more depend on the algorithm which is used to find them. There is no standard algorithm here, as the peak finding is based on up-sampling the signal and detecting the peaks in that new signal. And as you know, there are several ways to change the sample rates.
The built in MFiT Apple Script ISP result is nearly Identical to the Wavelab ISP result above (in the 16 bit examples).
The encode AppleScript automatically takes care of the exact correct built-in Apple SRC usage (if the source wav is not 44.1 already).
The Wavelab ISP result would not even need to be used if the entire existing MFiT AppleScript chain and Afclip were used. The ISP result is taken care of by Afclip.
I did have to edit the aac to wav applescript to get real 16bit and 32f wav files out. It defaults to 24bit, so I had to change LEI24 to LEI16 and LEF32 in two spots. But Afclip converts to 32f automatically for it’s analysis / printout. It’s incredibly simple and nearly all automatic. And it’s the only way to get exact Apple MFiT analysis and results - to use their entire official codec/src/settings chain, which is exactly what the AppleScript droplets and Afclip are, a fixed automatic process with no options, yielding results identical to MFiT files sold in the iTunes store.