• New parameter "--adaptivelink <lo hi> / off". Adds check for stereo audio where relative signal strength of the mid and side virtual channels are compared and, if the ratio is above hi or below lo, the bits to remove for left and right audio channels will be the same, i.e. the lower of the bits to remove calculated for the channels. Adaptivelink is automatically applied for stereo audio but can be disabled using "--adaptivelink off". Lo and hi are valid in the range -3.0 < n < 8.0 and lo must be less than or equal to hi. Defaults are -2.0 and 2.0 respectively.

• Change to "--adaptivelink <lo hi> / off" parameter; range of validity remains the same, defaults are now lo = -1.1 and hi = 1.1
• Previous removal of the check of alt-average during the determination of bits to remove when weighted shaping method and experimental shaping gain curve are selected has been reverted. Now when weighted shaping method and experimental shaping gain curve are selected a modified variant of the alt-average check is performed.

FLAC -8 (-b 512) -> 317,271,421 bytes  27.685s   4.812s
FLAC -5 (-b 512) -> 317,763,446 bytes   6.553s   4.803s
HALAC (normal)   -> 325,493,443 bytes   2.662s   2.905s
FLAC -8 (default)-> 332,940,950 bytes  12.587s   3.784s
FLAC -5 (default)-> 334,934,310 bytes   4.765s   3.676s
WAVPACK (high)   -> 422,790,502 bytes  31.636s  16.958s // default
WAVPACK (high)   -> 393,544,400 bytes  28.639s  18.139s // blocksize=512
OPTIMFROG (high) -> 493,764,226 bytes  66.879s  56.158s

It's only just dawned on me that the block size used in the lossless compression above is incorrect for 96kHz audio processed with lossyWAV - it should be 1024 not 512.

    Global.Codec_Block.duration = OneOver[100];
    Global.Codec_Block.bits = std::max(8, nRoundEvenInt32(nlog2(Global.Codec_Block.duration * Global.sample_rate)));
    Global.Codec_Block.Size = PowersOf.TwoInt[Global.Codec_Block.bits];
    Global.Codec_Block.Size_recip = PowersOf.TwoX[TWO_OFFSET - Global.Codec_Block.bits];
    Global.Codec_Block.bit_shift = Global.Codec_Block.bits - 9;
    Global.Codec_Block.duration = double(Global.Codec_Block.Size) / Global.sample_rate;

Total 1,915,809,594 bytes (12 tracks, 24 bit, 2 ch, 96.0 khz)

Code: [Select]

FLAC -8 (-b 512) -> 317,271,421 bytes  27.685s   4.812s
FLAC -5 (-b 512) -> 317,763,446 bytes   6.553s   4.803s
HALAC (normal)   -> 325,493,443 bytes   2.662s   2.905s
FLAC -8 (default)-> 332,940,950 bytes  12.587s   3.784s
FLAC -5 (default)-> 334,934,310 bytes   4.765s   3.676s
WAVPACK (high)   -> 422,790,502 bytes  31.636s  16.958s // default
WAVPACK (high)   -> 393,544,400 bytes  28.639s  18.139s // blocksize=512
OPTIMFROG (high) -> 493,764,226 bytes  66.879s  56.158s

FLAC -8      : 308,758,405 bytes  18.634s   4.481s // block_size 1024
FLAC -5      : 309,764,795 bytes   5.541s   4.476s // block_size 1024
HALAC -normal: 310,723,761 bytes   2.356s   2.856s // block_size 1024
WAVPACK -hx  : 352,913,408 bytes  86.562s  16.485s // block_size 1024
WAVPACK -h   : 360,985,944 bytes  36.981s  17.496s // block_size 1024

In light of discussion in this thread, I am considering removing the ability to create correction files / merge lossy and correction files from lossyWAV.

As correctly observed in the thread, while WavPack enjoys the ability as a codec to create lossy / correction file pairs and, crucially, automatically reintegrate them for playback and conversion from lossless, lossyWAV as a DSP does not.

Removing creation and re-integration from correction files would reduce code complexity and allow more easy moves to, for example, changing bits-per-sample on the fly between input to and output from lossyWAV.

With the removal of the correction / merge features there is no compelling reason now to retain the "fact" chunk that lossyWAV inserts into processed audio files, N.B. but only if those files are written as files, i.e. the "fact" chunk is not inserted into processed audio written to stdout.

Therefore I am going to remove the creation / insertion of 'fact' chunks from lossyWAV completely. This will further simplify the code.

One way to tell if an integer PCM file has been processed with lossyWAV is to "OR" all of the samples in a block and see how many zeroed LSBs there are.

Regarding block size in lossyWAV it's as previously discussed, i.e. it's related to sample-rate.