Lately I've become interested in the question if I should use mppenc 1.14 or 1.15r (standard + higher).
Trying to find audible differences and ABX them (talking about my own music, not known problem samples) by listening is awfully time-consuming. So I tried to find a smarter way (this might be useful for testing other codecs than Musepack too). I've figured out two possibilities and want to know what you think about it.
_A_
1. Take the original (o.wav) and the decoded copy (c.wav) and do a wave substraction (d.wav = c.wav - o.wav).
2. Get d_a.wav by amplifying d.wav by something like 10...20dB.
3. Produce a file with emphasized differences by adding d_a.wav + o.wav = e.wav
If clipping occurs somewhere in 1.-3., everything needs to be amplified by ~-1...-6dB in a 1st step ("0.")
4. Now differences between o.wav and e.wav should be clearly audible. Pick out the most noticable/annoying, note their positions and do the whole thing with lower amplification.
With some luck there'll be differences that are still ABXable with 0dB amplification (which means e.wav = c.wav)
_B_
The idea behind this approach is this: If at a certain position the difference between original and copy is relatively big (=loud/high energy) while o the original signal loudness/energy is relatively low the chance to find a ABXable difference here is bigger than at a position where it's the other way round.
I'd try to find these positions using CoolEdit like this (I don't know if it makes any sense, but if it does, I'm sure there are better ways
):1. d.wav = c.wav - o.wav
2. use "mix paste - multiply" effect (result = input1*input2/32768; here abbreviated as "*") like this:
d2.wav = d.wav * d.wav //High sample values in d2.wav is what we'll be looking for
o2.wav = o.wav * o.wav //Low sample values in o2.wav is what we'll be looking for
3. create inv_help.wav: all sample Values 32767, same length as o.wav
4. o2-.wav = inv_help.wav - o2.wav //High values in o2.wav are low in o2-.wav and the other way round, so we're looking for high values in o2-.wav now.
5. Result: r.wav = o2-.wav * d2.wav
If this idea works, the peaks of r.wav might contain some positions that can be ABXed successfully. (I'm not sure what kind of peaks to look for - maximum sample values, RMS Power (analyzed by CoolEdit), maybe even the most colorful spots in spectral view ...)
I guess it's possible to do this in a better way than multiplying sample values with themselves - maybe some kind of filtering. Any ideas?
Thanks in advance for your input!
Cheers tigre