iTunes has a feature called sound check, which scans all of the tracks in your music library and determines a level of volume adjustment that can be applied to each track so that they play back at a more or less comparable volume. BitPerfect used to support sound check, but along the way iTunes changed the way in which they implemented it internally and so we dropped support for it. Over the last few updates to iTunes, however, the sound check feature has remained pretty much stable and unchanged, so we decided maybe it is time to implement it again in BitPerfect.
Nobody is quite sure how sophisticated the algorithm is with which iTunes determines the amount of volume adjustment to be applied by sound check. But I wouldn’t be betting my house on it being anything beyond something relatively crude. For sure, the net effect of enabling sound check is to populate a metadata tag which shows up in the “Get Info…” dialog window under the “File” tab. This number is basically tells you how much volume adjustment is applied to the track by iTunes in order to “normalize” is playback volume.
These numbers can be negative, in which case the track will be attenuated for playback, or positive in which case gain needs to be applied. If the volume number is 0dB it appears that this “Volume” tag stays blank. Of course attenuation is not a problem, but if we apply gain then we have to be aware of the possibility that the loudest parts of the track may be clipped. Quite how this is handled in iTunes is not clear. It is likely that iTunes uses a crude soft-clipping algorithm. I have previously posted on what I think about that. BitPerfect does not go in for crude anything.
The biggest problem with clipping, soft or otherwise, is the creation of aliased harmonics. The best approach is therefore to upsample as far as you can before soft clipping so that the aliases will lie predominantly outside of the audio bandwidth and then down-sample, using the anti-aliasing filter to eliminate the aliases. All in all a rather hefty processing loop for something that at the end of the day is still going to introduce very significant distortions. I suppose this is something we might introduce in the future as a specialist plug-in if the demand is there.
What used to happen was that iTunes wrote the volume adjustment information into each file’s metadata. BitPerfect could then read this value when playing back the file. However, for some reason, iTunes made a change to that system. Now, it only writes that information into some files and not others. Those that get this data written to them include MP3 and AAC formats, while those that don’t include Apple Lossless. I have no idea who it was in Apple that decided this was a GOOD IDEA. Since Apple Lossless files represent the vast majority of files listened to by BitPerfect users, it means that we cannot support sound check using this method. I suppose the argument is that you shouldn’t be using sound check if you’re listening to Apple Lossless music, and maybe particularly not if you are listening via BitPerfect, but that’s a little bit too Orwellian for me.
The other way to get this information is by interrogating the iTunes Library Framework, one of the many inter-process communication protocols that Apple provides, none of which work very well. We have been down this road before with Apple. The way it works is that when BitPerfect loads it asks iTunes for an iTunes Library Framework Object. Sounds simple enough. However, last time we tried this we found that on some systems when BitPerfect tries to load the Framework Object, iTunes refuses to respond. We could never figure out what it was about a system that made iTunes behave that way. At that time, the reason we tried using the Framework Object was to manage the Access Permissions scan to improve the scanning speed. Consequently, since Access Permissions are a necessity, we were forced to drop that method entirely.
But now we are looking at it again as a possible way to re-introduce support for sound check. And we’re finding that the old problem is still there. On one of our three main test platforms we cannot get iTunes to deliver the Framework Object to BitPerfect. On the others it is not a problem at all. If the Framework Object is delivered to BitPerfect then it can support sound check, but if it is not then it has no way to access the sound check values.
We are wondering what to do about that in the short term. We have a new update to BitPerfect that we want to release soon. Do we release it with sound check support knowing that for some people - and we have no way of knowing how many - it isn’t going to work? Or do we not release without sound check support?
I’m thinking we’ll release it with the problematic sound check support. For those who are unaffected by the problem they will have access to the sound check function. For those who encounter the problem the sound check function won’t work, but it would be no different to if we hadn’t included it in the first place. Some feedback from concerned users would be welcome :)
