Hydrogenaudio Forums

Lossy Audio Compression => Other Lossy Codecs => Topic started by: Nick.C on 2010-05-17 21:47:01

Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-17 21:47:01
Following the release of lossyWAV 1.2.0, I feel it is (yet again) time to kick off development of the next minor release.

Items currently on the list for inclusion in 1.3.0:
If you have any ideas, requests, suggestions, code optimisations, etc, please post them here.

Link to hydrogenaudio wiki lossyWAV article. (http://wiki.hydrogenaudio.org/index.php?title=LossyWAV)

Suggested foobar2000 converter setup:

lossyFLAC:
Code: [Select]
Encoder: c:\windows\system32\cmd.exe
Extension: lossy.flac
Parameters: /d /c c:\"program files"\bin\lossywav - --quality standard --silent --stdout|c:\"program files"\bin\flac - -b 512 -5 -f -o%d --ignore-chunk-sizes
Format is: lossless or hybrid
Highest BPS mode supported: 24
lossyTAK:
Code: [Select]
Encoder: c:\windows\system32\cmd.exe
Extension: lossy.tak
Parameters: /d /c c:\"program files"\bin\lossywav - --quality standard --silent --stdout|c:\"program files"\bin\takc -e -p2m -fsl512 -ihs - %d
Format is: lossless or hybrid
Highest BPS mode supported: 24
lossyWV:
Code: [Select]
Encoder: c:\windows\system32\cmd.exe
Extension: lossy.wv
Parameters: /d /c c:\"program files"\bin\lossywav - --quality standard --silent --stdout|c:\"program files"\bin\wavpack -hm --blocksize=512 --merge-blocks -i - %d
Format is: lossless or hybrid
Highest BPS mode supported: 24
Enclose the element of the path containing spaces within double quotation marks ("), e.g. C:\"Program Files"\directory_where_executable_is\executable_name. This is a Windows limitation.

Change log 1.3.0: 06/08/2011
Introduction of fixed noise shaping using curve based on SebastianG's noise shaping IIR filter previously used in 1.2.0. Parameter -s, --shaping [n] takes optional parameter (0<=n<=1) or is set automatically depending on quality setting;
Code improvements.
Bug hunting.

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Change log beta 1.2.3p RC11: 14/06/2011
(Minor) modifications to --adaptive parameter;
Introduction of -W, --width <n> parameter (80<=n<=255) to allow user to select width of certain output options;
Introduction of -H, --histogram parameter to display 64-bin histogram of sample values;
Code improvements.
Bug hunting.

Change log beta 1.2.3o RC10: 16/05/2011
(Minor) modifications to --adaptive parameter.
Removal of fast / lower precision sqrt and log functions - seems to improve adaptive shaping "accuracy".
Bug hunting.
Previous beta versions / release candidates left up to allow side-to-side comparison, however, this is functionally very similar to beta 1.2.3n RC9.

Change log beta 1.2.3n RC9: 13/05/2011
Modifications to --adaptive parameter. Now allows user to disable default gain curve (use nogain) and default frequency warping (using nowarp) after the --adaptive parameter. Filter order still user selectable. Parameter takes multiple sub-parameters.
Bug hunting.

Change log beta 1.2.3m RC8: 11/05/2011
Modifications to adaptive noise shaping method. Now only uses "current" FFT results rather than using historical data as well.
Bug hunting.

Change log beta 1.2.3l RC7: 09/05/2011
(Minor) modifications to adaptive noise shaping method.
Bug hunting.

Change log beta 1.2.3k RC16: 06/05/2011
(Minor) modifications to adaptive noise shaping method.
Bug hunting.
Slight change to the --spread parameter (related to output of codec-block processing and subsequent spreading function(s)) - now indicates whether the static or dynamic maximum-bits-to-remove limits kicked in during processing (i.e. all FFTs for a particular codec block indicated more bits could be removed but bits-removed was limited to static and dynamic limits).

Change log beta 1.2.3j: 04/05/2011
Modifications to adaptive noise shaping method;
Change to --static parameter; maximum bits-to-keep now limited to bits-per-sample - 4.

Change log beta 1.2.3i: 22/04/2011
Modifications to adaptive noise shaping method;
DC offset now removed from audio data (and bit-removed data and correction data, when enabled) prior to analysis - seems to have improved "Furious" sample problem.

Change log beta 1.2.3h: 16/04/2011
Modifications to adaptive noise shaping method: higher sample-rates now treated differently - hopefully now avoiding the suspected phase related distortion encountered with 384kHz samples.

Change log beta 1.2.3g: 12/04/2011
Modifications to adaptive noise shaping method: --warp parameter removed due to complexity of selecting correct value. The value is now frequency dependent to allow for consistency in the portion of the warped spectrum associated with the frequency range of interest (up to 16kHz by default);
Modifications made to handling of sample-rates other than 44.1kHz. I realised that as all the testing has pretty much been carried out at that rate then there may be issues with handling other sample-rates. There were. I think that they're now fixed.

Change log beta 1.2.3f: 24/03/2011
Modifications to adaptive noise shaping method;
Addition of the --static parameter to allow the user to increase the number of (static) minimum-bits-to-keep in the range 7<=n<=16, default=6.

Change log beta 1.2.3e: 16/03/2011
Modifications to adaptive noise shaping method.

Change log beta 1.2.3d RC5: 28/02/2011
Change to parameter limits for -A, --adaptive: now 64<=n<=256;
Change to order of lower quality presets:Code tidy up and optimisation.
This is release candidate #5 for lossyWAV 1.3.0.

Change log beta 1.2.3c RC4: 22/02/2011
Parameter -i, --impulse removed. The shortest FFT (32 samples for 44.1/48kHz input) is now enabled by default for all quality settings, previously for int(q)>0. Can be disabled using --analyses 2 (default number of analyses is now 3).
A change to quality preset selection. Parameter -q, --quality will now accept a numeric value in the range -5 to 10 as before but also a short and long preset name as follows:Code tidy up and optimisation.
This is release candidate #4 for lossyWAV 1.3.0.

Change log beta 1.2.3b RC3: 16/02/2011
--classic and --altpreset quality systems removed;
Fixed noise shaping removed;
Adaptive noise shaping now enabled by default. Use --adaptive OFF to disable. Parameter will still take numeric input to set number of taps for FIR filter used.
Remapping of quality presets as follows:Code tidy up and optimisation.
This is release candidate #3 for lossyWAV 1.3.0.

Change log beta 1.2.3a RC2: 11/02/2011
(Very) minor changes to the adaptive noise shaping algorithm. Bug-fix to avoid divide-by-zero in levinson-durbin recursion.
Replacement of default internal settings, ranging from -5 to 10. Existing defaults now accessible using --classic parameter.
This is release candidate #2 for lossyWAV 1.3.0.

Change log beta 1.2.2z RC1: 10/01/2011
Minor changes to the adaptive noise shaping algorithm;
This is release candidate #1 for lossyWAV 1.3.0.

Change log beta 1.2.2y: 08/01/2011
Minor changes to the adaptive noise shaping algorithm, now a bit faster.

Change log beta 1.2.2x: 05/01/2011
Minor changes to the adaptive noise shaping algorithm - now takes into account long FFT analysis results for previous codec-block as well as present codec-block; Changes made to curve which modifies shape of desired filter output per codec-block-channel.

Change log beta 1.2.2w: 02/12/2010
Minor changes to the adaptive noise shaping algorithm; default FIR filter size=64;
Bug found in processing of multi-channel audio - also fixed in version 1.2.0 as maintenance release 1.2.0b (see Validated News);
Code tidy up.

Change log beta 1.2.2t: 11/11/2010
Minor changes to the adaptive noise shaping algorithm (max FIR filter size=512);
-X, --sortspread parameter removed;
-F, --fftw parameter removed. libfftw3-3.dll (double precision) used automatically if found;
Code tidy up.

Change log beta 1.2.2s: 08/08/2010
Further changes to the adaptive noise shaping algorithm;

Change log beta 1.2.2r: 26/07/2010
Bug-fixes and minor changes to the adaptive noise shaping algorithm;
Compatibility with libfftw3f-3.dll removed (single precision) to significantly simplify code;
Removal of added dither in bit-removal algorithm when adaptive noise shaping active.

Change log beta 1.2.2q: 29/06/2010
Further changes to the adaptive noise shaping algorithm;
Change to bit-removal algorithm when adaptive noise shaping active - dither introduced.

Change log beta 1.2.2p: 21/06/2010
Further changes to the adaptive noise shaping algorithm.

Change log beta 1.2.2n: 21/06/2010
Further changes to the adaptive noise shaping algorithm. Modification made to the high frequency portion of the desired shape.

Change log beta 1.2.2m: 17/06/2010
Further changes to the adaptive noise shaping algorithm. Now uses the results of both the long and short FFT analyses when determining the desired shape of filter.

Change log beta 1.2.2k: 11/06/2010
Desired shape of filter now changes more gradually per codec-block rather than totally;
Fix to calculation of frequency distribution to allow more accurate comparison of input and output.

Change log beta 1.2.2j: 04/06/2010
Temporary fix to stop spikes in output - attempt #1.

Change log beta 1.2.2i: 03/06/2010
Bug fix in FFT routine selection process.

Change log beta 1.2.2h: 03/06/2010
Bug fix in adaptive noise shaping method.

Change log beta 1.2.2g: 01/06/2010
Modifications made to adaptive noise shaping method.

Change log beta 1.2.2f: 31/05/2010
Modifications made to adaptive noise shaping method. Change in filter behaviour at higher frequencies.

Change log beta 1.2.2e: 31/05/2010
Modifications made to adaptive noise shaping method. Better filter resolution achieved (I think). --adaptive parameter now takes an integer value as the order of the FIR filter. Valid in the range 16<=n<=128, default=32.

Change log beta 1.2.2d: 29/05/2010
Modifications made to adaptive noise shaping method. Better resolution (I think) of the filter - interim beta - still work to do on this.

Change log beta 1.2.2c: 28/05/2010
Modifications made to adaptive noise shaping method. Attempt #1 to fix the low-frequency error.

Change log beta 1.2.2b: 27/05/2010
Modifications made to adaptive noise shaping method. Attempt #1 to fix clicking error.

Change log beta 1.2.2a: 26/05/2010
Further progress made with SG's adaptive noise shaping method. The --adaptive parameter now takes a parameter (in the range -1<n<1) to allow the warping factor to be changed. Error found and fixed in remove_bits routine (for adaptive-shaping).

Change log beta 1.2.1a: 25/05/2010
Further progress made with SG's adaptive noise shaping method. Extremely simplistic psy-model in place. Enable by adding --adaptive to the command line.
Post-analysis of the bit-removed audio data can be performed using the --postanalyse parameter in conjunction with the --freqdist parameter.

Change log pre beta 1.2.1a: 17/05/2010
Code optimisations;
Major part of the implementation of SG's adaptive noise shaping;
Modification of fftw_interface unit and FFT handling routines to allow the use of libfftw3f-3.dll as well as libfftw3-3.dll (-F, --fftw <single/double/off>);
Implementation of the spectral plot (--freqdist) for input and optionally output audio data.[/size]
Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2010-05-18 00:09:44
I'm going to enjoy this thread!

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-05-18 22:26:15
I've been waiting for this thread and finally here it is.

No ideas or suggestions at the moment though, but some will most likely appear when the discussion kicks off.
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2010-05-19 13:19:01
  • Implementation of SG's adaptive noise shaping method;
  • Identification and adaptation of a psy-model to use in conjunction with the new noise shaping method;

Do I understand correctly what we're aiming for?
The noise shaping is so we can add more noise but still hide it, this could give better compression. But with noise shaping, the used codec will have worse compression as a result, which will (partly) eliminate this advantage.
It will be interesting to see how much room there is for applying noise shaping before it becomes counter productive.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-19 13:38:53
The lossless codec is especially less efficient if added noise is in the very high frequency range.
With an adaptive noise shaping there is hope that overall efficiency will improve.

@Nick: Nice to see you still improving lossyWAV. Thanks a lot.
Title: lossyWAV 1.3.0 Development Thread
Post by: sauvage78 on 2010-05-19 13:44:17
Quote
Nice to see you still improving lossyWAV. Thanks a lot.
Same here.

I like the fact that lossywav exist as an alternative no matter if I use it or not. The idea behind it is great & makes it worthy.

Quote
Implementation of SG's adaptive noise shaping method

... even if I don't get what it means  This have been in the TODO list for so long that I'll be curious to hear what it sounds like !!!
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-22 13:09:31
Right, I've got the guts of SG's adaptive noise shaping (ANS) algorithm working, up to a point. I think that I have the initial state of the FIR filter working but am not sure how to use it - the existing static noise shaping (SNS) algorithm uses an IIR filter.

If anyone with experience of using FIR filters were to offer some hints, that would be very much appreciated.

I've got the optional use of single / double precision FFTW DLLs in place, as well as the spectral plot. After a bit more work on ANS, I will release a beta version and source.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-05-22 21:18:48
I don't know how much you know and how much you don't know, plus I myself have absolutely no idea what FIR filters are , so I'm not sure if anything I come up with will be of any use, but I'm going to try anyway.

This seems to have some implementation notes (http://www.dspguru.com/dsp/faqs/fir), although they're for C and assembly so I don't know if it'll be of any use.

This is also about implementing it in C. (https://ccrma.stanford.edu/~jos/filters/FIR_Software_Implementations.html) (I've gotten that from here (https://ccrma.stanford.edu/~jos/filters/Finite_Impulse_Response_Digital.html).)

This (http://www.dsprelated.com/dspbooks/sasp/FIR_Digital_Filter_Design.html) seems to have a bunch of details about FIR filters.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-25 19:59:09
Following some very constructive help from SG, lossyWAV beta 1.2.1a is attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: SebastianG on 2010-05-25 21:16:48
Do I understand correctly what we're aiming for?
The noise shaping is so we can add more noise but still hide it, this could give better compression. But with noise shaping, the used codec will have worse compression as a result, which will (partly) eliminate this advantage.

"hiding the noise" and "noise partly eliminates this advantage" sort of contradict each other. If it's properly hidden ("behind the original signal") it will NOT affect the quantized signal's predictability in any significant way. And that's the goal I'd be aiming for.
(1) apply psychoacoustic model to determine tolerable noise levels
(2) restrict local SNRs not to go below a certain threshold
(3) derive noise shaping filter and wasted_bits from the results

#1 makes sure that the noise is below the masking thresholds
#2 makes sure that the noise doesn't hurt predictability.

Cheers!
SG
Title: lossyWAV 1.3.0 Development Thread
Post by: Enig123 on 2010-05-26 08:57:32
SebastianG,


If I understand correctly, dither with noise shaping is tend to be used as the last step of audio processing chain. How worse it could be if dithered before, like lossyWAV with ANS, or the product of CD, and then dither with noise shaping another time at the end of playback side?

Regards,
Enig123
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-26 12:30:35
lossyWAV beta 1.2.2a attached to post #1 in this thread.

They say that a picture is worth a thousand words - the following images indicate that the implementation of SG's adaptive noise shaping method in beta 1.2.2a is pretty much putting the noise where I want it to be, i.e. behind the signal.

[edit] Superseded - images removed. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: moozooh on 2010-05-26 13:19:08
Excellent job, Nick. :) Looking forward to the 1.3.0!
Title: lossyWAV 1.3.0 Development Thread
Post by: SebastianG on 2010-05-26 19:44:15
If I understand correctly, dither with noise shaping is tend to be used as the last step of audio processing chain.

I don't know. It certainly is a possibility to "work" in 24 bit and do a word length reduction to 16 bit with a dithering noise shaping quantizer so you can create an audio CD for example.

How worse it could be if dithered before, like lossyWAV with ANS, or the product of CD, and then dither with noise shaping another time at the end of playback side?

I don't understand. Why would you be dithering at the "end of the playback side"?

As for LossyWav: I think dithering is neither appropriate nor necessary. The probability of the signal being "self-dithering" is very high if a noise shaper is used that "hides the noise behind the signal".

It's possible that "dithering" means something different to you.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-26 21:06:27
Average bitrate for my usual test set of various pop music:

lossyWAV_beta_1.2.2a -P --altpreset --adaptive: 368 kbps (compared to 379 kbps without --adaptive)
lossyWAV_beta_1.2.2a -Z --altpreset --adaptive: 314 kbps

This is pretty interesting.

I'm going to do some listening tests within the next days focusing on -Z --altpreset --adaptive.
Title: lossyWAV 1.3.0 Development Thread
Post by: Enig123 on 2010-05-27 03:13:53
I don't understand. Why would you be dithering at the "end of the playback side"?

As for LossyWav: I think dithering is neither appropriate nor necessary. The probability of the signal being "self-dithering" is very high if a noise shaper is used that "hides the noise behind the signal".

It's possible that "dithering" means something different to you.


For example, playing a "dithered" lossyFLAC with foobar2000 and let the output dithering to 16-bit, which is possible with volue adjustment and the foobar2000 uses float point for internal processing. There will be two dither processings. I wonder if that would cause some negative effect in terms of quality.
Title: lossyWAV 1.3.0 Development Thread
Post by: SebastianG on 2010-05-27 09:43:54
I wonder if that would cause some negative effect in terms of quality.

Not more than usual.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-27 11:15:16
I just did some listening tests.

Problems for the adaptive noise shaping are
- Bibilolo (http://dl.dropbox.com/u/2681777/ProblemSamples/bibiloloEssence.wav)
- Furious (http://dl.dropbox.com/u/2681777/ProblemSamples/Furious.wav).

Kind of low frequency artefacts are added, annoying with -Z --adaptive, much better but still easily ABXable with -Z --altpreset --adaptive.

Maybe shaped noise is a problem when concentrated at low frequencies.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-27 12:54:29
Thanks for that - I'll get to work on it and see what comes out....
Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2010-05-27 14:58:39
There are clicks (waveform discontinuities) in the added noise at some block boundaries, e.g. Furious.wav --adaptive -Z, look at the correction file at samples 166400, 166912, 171008, 171520 etc.

I can't hear it, but I doubt it should be happening.

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2010-05-27 15:19:20
Maybe shaped noise is a problem when concentrated at low frequencies.

The next thing on the list was a sort of (I hope simple) PSY-model, it could be it is already needed 
@Nick: Thanks for the spectrum pictures, it made it much more clear to me what the idea of ANS is.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-27 18:43:25
Thanks for the feedback on "clicking", David - I will see what I messed up and revert.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-27 19:13:28
I can confirm the added noise can be described as kind of clicking.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-27 21:09:53
lossyWAV beta 1.2.2b attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-05-28 01:33:17
Modification of fftw_interface unit and FFT handling routines to allow the use of libfftw3f-3.dll as well as libfftw3-3.dll (-F, --fftw <single/double/off>);

By the way, what exactly is the difference between using libfftw3f-3.dll and libfftw3-3.dll? Does lossyWAV only use one or both if they're both present?
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-28 06:24:09
lossyWAV 1.2.0 makes use of libfftw3-3.dll for double precision FFT analyses. libfftw3f-3.dll is the single precision variant. lossyWAV >1.2.0 can use either (but not both). The request was made a while ago to allow the use be able to use both (not at the same time) - apparently single precision is faster (although not by very much at all from my testing).
Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2010-05-28 09:38:52
lossyWAV beta 1.2.2b attached to post #1 in this thread.
That's fixed the problem I saw.

As I couldn't hear it before, I'll leave the listening to halb27

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-28 16:15:35
I just tried 1.2.2.b -Z --adaptive on bibilolo (bibiloloEssence as before to be precise) and furious.

It's much better now but it's not hard to ABX (I ABXed the last 0.8 sec. of bibiloloEssence and the last 0.9 sec. of furious).
It still sounds like spontaneously added low frequency noise or kind of rumbling.

Maybe -Z (without --altpreset) can't be really competitive qualitywise, but for bibiloloEssence it does take 433 kbps which IMO should produce a better quality in case everything works alright. So I think bibiloloEssence is a good sample for improving things.

I looked at the spectograms you gave for badvilbel, Nick. Isn't the noise up to 1 kHz a bit too strong? Loos like a frequency block of rather strong noise compared to other frequency regions, and at 1 kHz our ears are pretty sensitive. Just a thought.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-28 16:42:14
I looked at the spectogram of the last 0.5 second of bibiloloEssence and that of the correction file.

For the last 0.5 sec. there's nearly no frequency content in the signal in the roughly 800 Hz to 7 kHz region. But quite a lot of noise is added in this range.
This happens also earlier in the track with a pretty week signal contents up to roughly 700 Hz and no signal contents between ~ 700 Hz and 7 kHz, while pretty strong noise is added especially in the 1-2 kHz range where our ears are very sensitive.
Maybe there can be special treatment for the sensitive range of roughly 1-3 kHz ensuring that SNR is always beyond a certain limit (if necessary by locally increasing SNR demands and/or by locally giving away noise shaping for the sake of a better SNR in this specific frequency range).
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-28 18:12:29
Thanks again for the fault-finding.... .

lossyWAV beta 1.2.2c attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-28 23:29:08
Nick, you must be a wizard being so fast with new versions!

I am a bit tired now after returning from a vaudeville show but couldn't resist doing a quick listening test of 1.2.2.c -Z --adaptive on bibiloloEssence and furious.
I'll repeat the test tomorrow, but for this quick test bibiloloEssence was fine.
With furious however there's still some (small) problem. Within the last second there's an artefact again, this time more clearly to be described as a kind of clicking. It's not very obvious though.

I did not think before that it will be possible to have lossyWAV going to be transparent on difficult samples with a setting yielding an average bitrate way below 300 kbps. And now it looks as if you're not far away from achieving this, Nick. Chapeau!
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-29 11:35:38
I repeated last night's test, now doing it very carefully.
But my result for bibiloloEssence is the same: it's transparent to me.
The result is also the same for furious (as was expected): I can ABX the last second 10/10.

The only new thing is that I have the impression that what I described as kind of clicking in furious (or some other kind of spontaneous irregularity in the 'music') isn't necessarily an error produced by the lossyWAV machinery. I'm not totally sure but I hear kind of the same 'irregularity' in the signal, at a much lower volume. The 'irregularity' is stronger in the lossyWAV result, that's why it isn't transparent, but it still resembles the original.

So maybe this isn't an error in the new machinery but corresponds simply to the fact that we're at very low bitrate with -Z --adaptive for what we can expect for the lossyWAV process (and the result is good, just not perfect).
For general use maybe the transparency border is at a little bit more demanding setting than -Z --adaptive.

Anyway in order to find samples worth while improving upon, and for optimizing lossyWAV, especially with respect to the adaptive noise shaping, I think it's appropriate at the moment to focus on -Z --adaptive.
I'll do more listening tests within the next days.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-29 11:40:45
Great news about bibilolo - very satisfying to get a positive result on the first attempt.

Thanks for all of the testing - I'm working on a new feature which will hopefully result in a better filter - should be posted this evening.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-05-29 20:41:19
Another interesting sample for testing:

- Wheeee (http://www.speedyshare.com/files/22688318/download/wheeee.flac).

Unfortunately my brother is watching something on the TV at the moment and my PC is in the same room so I haven't had a chance to test this sample properly but I did listen a bit at the difference between the original and what you get after -Z --adaptive and it sounds interesting. It's also amazing how well the added noise adapts to the signal, in this sample it's certainly well visible.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-29 21:10:43
Thanks for the sample - having a bit of computer trouble....

I installed the Fisher Price Digital Arts & Crafts Studio software on the family PC (my development machine....) and it crashes with boring regularity when .NET Framework 1.1 is installed. Unfortunately, that is required by Borland Turbo Delphi Explorer 2006 - my development environment. I am therefore trying to implement a fix which removes the dependencies on .NET 1.1 from my Delphi installation. No update tonight (unless I get through this much faster than anticipated).
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-29 21:16:59
@doccolinni: Can you tell a bit about at what second the issue arises?

@Nick: Don't hurry, you're extremely fast anyway.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-05-29 21:22:57
@doccolinni: Can you tell a bit about at what second the issue arises?

Like I said, I couldn't test and listen to the sample properly, but I'll do it later tonight, so the reason why I linked to that sample was not because I identified an issue but because I thought it'd be a good sample for testing lossyWAV's noise shaping because of its complicated spectrum. I know that's not how things here usually work and I apologise if you expected there to be some issue I've already identified, but like I said I'll listen carefully to the sample later tonight and see if there are any identifiable artefacts.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-29 21:27:53
Yes, it's an interesting sample for looking at how adaptive noise shaping is doing. And it's working very well when looking at the spectograms.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-05-29 21:39:43
Yes, it's an interesting sample for looking at how adaptive noise shaping is doing. And it's working very well when looking at the spectograms.

My point exactly, though I hope I will get to actually properly listen to how lossyWAV is doing on this sample later tonight when my brother goes to sleep.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-05-29 22:08:57
This is the spectrum of the original. (http://img153.imageshack.us/img153/9966/spectroriginal.png)

This is the spectrum of the noise added by lossyWAV with -Z --adaptive. (http://img52.imageshack.us/img52/8465/spectrnoise.png)
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-29 22:40:11
lossyWAV beta 1.2.2d attached to post #1 in this thread.

[edit] Spectrograms removed - superseded. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-05-29 22:42:50
wheee sample lwcdf spectrogram.

Wow, that looks much smoother! Great job, Nick!
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-29 22:51:41
 Thanks - as I said in the change log, this is an interim step. I was using the data collated to produce the --freqdist spectrogram as the input to the adaptive noise shaping. This had 32 elements - which I think corresponds quite well with the blocky nature of your noise spectrogram. As an interim measure, I have interpolated this out to 128 elements and fed that output to the ANS algorithm. A better way would be to use a 256 sample FFT to collect the data for the input to the ANS algorithm. I will get onto this over the next few days.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-05-29 23:12:34
Indeed, the new noise (http://img9.imageshack.us/img9/2855/spectrnoisenew.png) looks a lot smoother than this one:

This is the spectrum of the noise added by lossyWAV with -Z --adaptive. (http://img52.imageshack.us/img52/8465/spectrnoise.png)

Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-30 22:33:14
My listening room wasn't quiet today so I couldn't test 1.2.2.d -Z --adaptive until few minutes ago.

Both bibiloloEssence and furious are transparent to me now.

I didn't start so bad with furious and thought I had a chance to ABX it though it was clear it was much harder than before. I arrived at 4/4 but got totally lost afterwards.
As it's late now I'm going to repeat the test tomorrow. Just to be sure.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-31 07:16:03
I repeated the test with furious using 1.2.2.d -Z --adaptive.
I arrived at 8/10 which is not a valid ABX result - at least it is a questionable one.
My both faults were with the 2 starting trials though, after that I was fine.

Taking it all together I think the result for furious is more or less on the edge of transparency - good enough for the portable quality setting.
I can't tell about the differences towards the original, I just have the feeling when ABXing that there is a (subtle) difference.

Listening experience of other members would be very welcome.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-31 12:55:23
lossyWAV beta 1.2.2e attached to post #1 in this thread.

[edit] spectrograms removed - superseded. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-31 14:21:27
I'm sorry to say that with this version I can ABX furious again pretty easily 10/10 (using -Z --adaptive).
The increased volume of the 'irregularity' is back.
Title: lossyWAV 1.3.0 Development Thread
Post by: SebastianG on 2010-05-31 16:13:55
I just want to comment on the "noise images". The "sharp responses" at high frequencies are not desirable. This doesn't reflect typical masking curves. The kind of noise shaping filter (frequency warped all-pole filter) is optimized to fit masking curves. Masking curves are typically rather smooth in higher frequency areas and can be quite selective (high frequency resolution) at lower frequencies. This is actually the point of using the frequency warping technique. The way Nick uses the filter right now doesn't seem to exploit that at all.

As for artefacts like clicks and pops etc this *could* be potentially explained by the exact mechanism Nick uses to switch from one filter to another. So, that's maybe a good place to look for the cause of artefacts. I specifically used a lattice filter structure for this reason. Lattice filters are quite stable when it comes to adapting the filter's parameters. But maybe there's a bug somewhere. To be honest I'm not completely sure about how changing the filter parameters interacts with frequency warping. It may be necessary to interpolate filters (over time) more smoothly. Nick, if you decide to do that you should convert the reflection coefficients to log-area-ratio (LAR) coefficients first, interpolate the LARs and convert them back -- or even better, interpolate the PSD curves and compute more than one set of filter coefficients for a block.

Cheers!
SG
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-05-31 22:31:18
lossyWAV beta 1.2.2f attached to post #1 in this thread.

[edit] Spectrograms removed - superseded. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-05-31 22:51:28
Bad news again, sorry.

Inspite of the increased bitrate there's a very audible added hiss now already in the first 0.7 second of furious (in the last second as well).
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-05-31 23:01:27
I haven't done any listening tests, but I can see by the noise spectrum that this is a bad move. I'm not trying to offend you, my criticism will be constructive.

Look at what's different between this:

Title: lossyWAV 1.3.0 Development Thread
Post by: shadowking on 2010-06-01 01:35:57
I will try and test things later this week. If I recall, -Z had big problems with serioustrouble, mandylion-sm, dear-sir. I'd be interested to hear the impact of -Z -A
Title: lossyWAV 1.3.0 Development Thread
Post by: aand on 2010-06-01 03:20:45
Hi! I can't get lossyWAV to work with FLAC or TAK. Here's the error I get:
Code: [Select]
1 out of 1 tracks converted with major problems.

Source: "J:\h\Jay-Z\14 - Jay-Z - My 1st Song.flac"
  An error occurred while writing to file (The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters) : "C:\Users\Administrator\Desktop\14 My 1st Song.lossy.flac"
Additional information:
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Windows\winsxs\wow64_microsoft-windows-commandprompt_31bf3856ad364e35_6.1.7600.16385_none_f15662b6686e5211\cmd.exe" /d /c  G:\Kits\"@ Codec"\lossyWAV_beta_1.2.2f\lossyWAV.exe  - --standard -P --stdout|G:\Kits\"@ Codec"\FLAC\flac.exe - -b 512 -8 -f -o"14 My 1st Song.lossy.flac" --ignore-chunk-sizes
Working folder: C:\Users\Administrator\Desktop\

  Conversion failed: The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters

I'm using Win7 x64.
Thanks.
Title: lossyWAV 1.3.0 Development Thread
Post by: Bonzaii on 2010-06-01 04:44:30
...cmd.exe" /d /c  G:\Kits\"@ Codec"\lossyWAV_beta_1.2.2f\lossyWAV.exe  - --standard -P --stdout|G:\Kits\"@ Codec"\FLAC\flac.exe - -b 512 -8 -f -o"14 My 1st Song.lossy.flac" --ignore-chunk-sizes...


Needs a space in the bolded part. Like this: ...-f -o "14 My 1st Song.lossy.flac"...

See if that works.

Edit: formatting.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-01 06:12:53
Command line: "C:\Windows\winsxs\wow64_microsoft-windows-commandprompt_31bf3856ad364e35_6.1.7600.16385_none_f15662b6686e5211\cmd.exe" /d /c  G:\Kits\"@ Codec"\lossyWAV_beta_1.2.2f\lossyWAV.exe  - --standard -P --stdout|G:\Kits\"@ Codec"\FLAC\flac.exe - -b 512 -8 -f -o"14 My 1st Song.lossy.flac" --ignore-chunk-sizes
You need to remove either --standard or -P (--portable) as both are quality pseudonyms they are mutually exclusive and lossyWAV exits with an error.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-01 08:24:44
Though there's certainly room for improvement for the way the adaptive noise shaping is working IMO version 1.2.2.d is very good already. I think it's a significant improvement over not doing adaptive noise shaping.
I didn't only listen to bibilolo and furious, but also enjoyed some regular music - at an average bitrate of 266 kbps for my regular test set!

@Nick: Can you please provide version 1.2.2.d for download again? (More generally speaking: apart from the current test version always that version which is expected to be the best one so far using adaptive noise shaping).

@shadowking: Wonderful to hear you're gonna do listening tests.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-01 12:26:55
lossyWAV beta 1.2.2g attached to post #1 in this thread.

[edit] spectrograms removed - superseded. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-01 15:26:49
I tried furious with 1.2.2.g -Z --adaptive.
Hiss is still there, maybe a tiny bit weaker than with 1.2.2.f.

For a comparison I tested 1.2.2.d again. It's the same thing. Same kind of hiss in the first 0.7 second. I just didn't here it before though it isn't very subtle.
Title: lossyWAV 1.3.0 Development Thread
Post by: aand on 2010-06-01 17:41:55
Code: [Select]
cmd.exe /d /c  G:\Kits\"@ Codec"\lossyWAV_beta_1.2.2f\lossyWAV.exe  - --standard --stdout|G:\Kits\"@ Codec"\FLAC\flac.exe - -b 512 -8 -f -o "02 Light It Up.lossy.flac" --ignore-chunk-sizes
  Conversion failed: The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters

I also put FFTW dlls in c:\windows(the 32bit ones, I suppose lossyWAV has to be compiled for x64 to work witth x64 DLLs).

SOLVED:
  I removed --silent to see if it worked, and I forgot to put it back, now it works! Hey, it was tired and it was late  .
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-01 17:54:37
@halb27: Would you have time to try different filter orders? The default is 32, but the upper limit is 128. Processing time suffers, but I wonder if the hiss might be reduced with an increase to the filter order.

@aand: Yes, lossyWAV is a 32-bit application and requires one of the 32-bit FFTW DLLs. (I still reckon it was "--standard" and "-P" on the command line that caused your crash....)
Title: lossyWAV 1.3.0 Development Thread
Post by: aand on 2010-06-01 18:35:42
Nope.

Quote
1 out of 1 tracks converted with major problems.

Source: "F:\@ Music Lossless\Cypress Hill - Rise Up [2010] FLAC\02. Light It Up.flac"
  An error occurred while writing to file (Could not start commandline encoder: The parameter is incorrect.  ) : "C:\Users\Administrator\Desktop\02 Light It Up.lossy.tak.lossy.tak.lossy.tak"
Additional information:
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: ""C:\Windows\winsxs\wow64_microsoft-windows-commandprompt_31bf3856ad364e35_6.1.7600.16385_none_f15662b6686e5211\cmd.exe"" /d /c  "G:\Kits\@ Codec\lossyWAV_beta_1.2.2f\lossyWAV"  - --standard --silent --stdout|C:\"Program Files (x86)"\foobar2000\Takc -e -p2m -fsl512 -ihs - "02 Light It Up.lossy.tak.lossy.tak.lossy.tak"
Working folder: C:\Users\Administrator\Desktop\

  Conversion failed: Could not start commandline encoder: The parameter is incorrect.

So TAK doesn't work. I don't know why it does the strange thing with the extension.

Edit: OK I removed "" from:
"C:\Windows\winsxs\wow64_microsoft-windows-commandprompt_31bf3856ad364e35_6.1.7600.16385_none_f15662b6686e5211\cmd.exe" , and I ended up with lossy.tak.lossy.tak.lossy.tak extension, and the conversion worked. A bit weird tho. I suppose it's in connection with the use of quote signs...
Title: lossyWAV 1.3.0 Development Thread
Post by: carpman on 2010-06-01 19:33:24
General LossyWAV setup help should probably have its own thread, no?

C.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-01 23:57:44
I don't know if I did something wrong or you did something wrong, but the spectrum I get for the noise added to "wheee" with -Z --adaptive definitely doesn't look like what you got (http://img88.imageshack.us/img88/4898/122gwheeespectrum.png).
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-02 09:52:14
@halb27: Would you have time to try different filter orders? ...


Yes, I will, though probably not today (I got water into my right ear this morning).
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-02 21:28:47
I don't know if I did something wrong or you did something wrong, but the spectrum I get for the noise added to "wheee" with -Z --adaptive definitely doesn't look like what you got (http://img88.imageshack.us/img88/4898/122gwheeespectrum.png).
It doesn't look right at all - have you been able to replicate it, and if so, what was your command line?
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-02 22:46:52
I don't know if I did something wrong or you did something wrong, but the spectrum I get for the noise added to "wheee" with -Z --adaptive definitely doesn't look like what you got (http://img88.imageshack.us/img88/4898/122gwheeespectrum.png).
It doesn't look right at all - have you been able to replicate it, and if so, what was your command line?

It ends up like that every single time. That's not the lwcdf file mind you, that's me manually opening both the original and the processed file in CoolEdit Pro 2.1 and copying one inverted over the other, which gives the difference between the two waveforms.

Command line is the same one I used for earlier testing:
Code: [Select]
lossyWAV wheeee.wav -Z --adaptive
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-02 23:06:25
.... but the .lwcdf.wav file is the difference between the two waveforms....

If you try:
Code: [Select]
lossywav wheeee.wav -Z -A -C
ren wheeee.wav wheeee_org.wav
lossywav wheeee.lossy --merge
comp wheeee.wav wheeee_org.wav
you should see that that is the case.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-02 23:10:00
.... but the .lwcdf.wav file is the difference between the two waveforms....

If you try:
Code: [Select]
lossywav wheeee.wav -Z -A -C
ren wheeee.wav wheeee_org.wav
lossywav wheeee.lossy --merge
comp wheeee.wav wheeee_org.wav
you should see that that is the case.

Done "lossywav wheeee.wav -Z -A -C", analysed the lwcdf file, got the same spectrum as the one I posted.
Title: lossyWAV 1.3.0 Development Thread
Post by: Bonzaii on 2010-06-03 03:49:49
Is there any way you can expand the Adapative parameter so that it can take values > 128? I've been using -q 1.5 -A 128 and it has reduced filesizes by quite a bit (most of my files are ~320 kbps, which is awesome). It also seems to theoretically improve sound, for a trade-off in encoding speed, but I could wait ~2 minutes a file IF it would, to a significant degree, shrink file size and (theoretically?) improve quality, but that may be just me.

Of course the important question is, does the adaptive filter seem to have much effect past a value of 128?

Thanks, and keep up the great work. I love tinkering around with the program.

-Bonzaii
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-03 08:12:02
Done "lossywav wheeee.wav -Z -A -C", analysed the lwcdf file, got the same spectrum as the one I posted.
There's an error in the adaptive shaping algorithm when the internal FFT routines are used - this error is not present when the FFTW DLLs are used. I'll get a fix out as soon as I can.

[edit] .... which might explain halb27's hiss problems - @halb27: do you have either of the FFTW DLLs installed on your PC? [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-03 08:32:28
I have libfftw3-3.dll and libfftw3l-3.dll in the same folder as lossyWAV.exe.
Is this enough to have them used?
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-03 08:49:03
Done "lossywav wheeee.wav -Z -A -C", analysed the lwcdf file, got the same spectrum as the one I posted.
There's an error in the adaptive shaping algorithm when the internal FFT routines are used - this error is not present when the FFTW DLLs are used. I'll get a fix out as soon as I can.

No problem. 

I have libfftw3-3.dll and libfftw3l-3.dll in the same folder as lossyWAV.exe.
Is this enough to have them used?

It used to be, I don't know if it is any more...

I've got libfftw3-3.dll in the same directory as lossyWAV as well and it still does the error, so I presume that you have to provide either -F or --fftw option on the command line. It was probably done so the program wouldn't be confused which .dll to use if both libfftw3-3.dll and libfftw3l-3.dll were present, because -F and --fftw now accept an option which can be either "single", "double" or "off", if I understand correctly.

So to make lossyWAV use FFTW libraries for Fourier transforms you need to provide one of these four options on the command line after "lossyWAV" and the filename:



That is, if I've understood it correctly.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-03 08:55:57
The DLL should be in a directory which is on the path, not necessarily in the directory where lossyWAV is - unless that directory is on the path. By default, lossyWAV will try to use libfftw3-3.dll (double precision) then, if that is not available, libfftw3f-3.dll (single precision) then, if that is not available, internal routines. The easy way to tell is to look at the end of the results line - if "[D]" is present, libfftw3-3.dll was used; if "" is present then libfftw3f-3.dll was used; if "" was used then the internal FFT routines were used.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-03 08:56:17
Ok, this is completely confusing me now.

libfftw3-3.dll is in the same directory as lossyWAV, yet when I add "-F double" to the command line it nonchalantly tells me that libfftw3-3.dll was not found and that it will proceed to use the internal FFT routines.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-03 09:02:34
At the command prompt enter "path" as a command. This will show you a list of the directories where Windows will look for executable files / dlls.

To append to this, you will need to use System Properties > Advanced Tab > Environment Variables and append the directory where your DLL is to the end of the path variable (either for your user or for the system) OR put a copy of the DLL into a directory that is already listed.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-03 09:05:55
At the command prompt enter "path" as a command. This will show you a list of the directories where Windows will look for executable files / dlls.

To append to this, you will need to use System Properties > Advanced Tab > Environment Variables and append the directory where your DLL is to the end of the path variable (either for your user or for the system) OR put a copy of the DLL into a directory that is already listed.

The thing is that, at least on Windows, every program considers the directory that it is run from to be in the path.

Nevertheless, I've tried adding libfftw3-3.dll to C:\WINDOWS\system32 - to no avail. Yes, that directory is definitely in the path (I've double-checked), lots of things would go haywire if it weren't.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-03 09:08:22
I tried and found the in the result line.

I use this bat-File (removed the --silent for internal/external testing) from foobar:

set path=%path%;c:\programme\flac
c:\programme\flac\lossyWAV_b122g.exe %1 %3 %4 %5 %6 %7 %8 %9 --below --silent
ren "%~N1.lwcdf.wav" "%~N2.lwcdf.wav"
rem c:\programme\flac\flac.exe -b 512 -l 6 -e -m -r 2 -f --totally-silent "%~N1.lossy.wav" -o"%~N2.flac"
c:\programme\flac\flac.exe -b 512 -8 -f --totally-silent "%~N1.lossy.wav" -o"%~N2.flac"
del "%~N1.lossy.wav"

So I locally set the path-variable to include my lossyWAV-folder (which is identical to the FLAC-folder in my case).

Adding -F double to the command line doesn't change things.
Even copying the dlls to C:\Windows\system32 which is natively in the path doesn't change things.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-03 09:10:08
Adding -F double to the command line doesn't change things.
Even copying the dlls to C:\Windows\system32 which is natively in the path doesn't change things.

Something is screwed up about lossyWAV's checking for the DLLs. That's a good thing though, because otherwise I would never have found out that bug which happens when internal FFT procedures are used.



edit: I'm not sure how Nick got the latest version of lossyWAV to use the FFTW DLLs though... :-/
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-03 09:14:13
Hmmmm.... Baffled now - I have my copy of the DLLs in "C:\UserData\Bin" and have appended that directory permanently to the path using the method mentioned above.

.... but what this seems to mean is that recent testing is flawed as we are not sure that the DLLs have been used, and there is a bug when using the internal routines.

As I said, I'll get a fix out as soon as I can - though probably not tonight as it's my son's birthday today so we're all going out for dinner.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-03 09:17:02
Hmmmm.... Baffled now - I have my copy of the DLLs in "C:\UserData\Bin" and have appended that directory permanently to the path using the method mentioned above.

.... but what this seems to mean is that recent testing is flawed as we are not sure that the DLLs have been used, as there is a bug when using the internal routines.

As I said, I'll get a fix out as soon as I can - though probably not tonight as it's my son's birthday today so we're all going out for dinner.

No probs, take your time, I'm surprised you manage to devote this much time to this as it is.

I'll try to figure out if there is any way I can force lossyWAV to use the FFTW DLLs... This has me completely stumped.  Programs don't deliberately choose to not load a .dll that's right under their nose!
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-03 09:23:03
Uh... I'm totally out of ideas... Maybe it's because my Windows are 64-bit? halb27, are your Windows 32-bit or 64-bit?

I am using 32-bit FFTW DLLs, so the files themselves are not the problem.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-03 09:45:13
I am using 32 bit-Windows (XP).
Title: lossyWAV 1.3.0 Development Thread
Post by: robert on 2010-06-03 09:45:32
Nevertheless, I've tried adding libfftw3-3.dll to C:\WINDOWS\system32 - to no avail. Yes, that directory is definitely in the path (I've double-checked), lots of things would go haywire if it weren't.

If you're on a 64 bit Windows, IIRC system32 is for 64bit DLLs. The 32bit ones should go into WOW64 folder. (But, I've no 64 bit Windows and I might be wrong, but that's what I remember)
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-03 09:49:10
Nevertheless, I've tried adding libfftw3-3.dll to C:\WINDOWS\system32 - to no avail. Yes, that directory is definitely in the path (I've double-checked), lots of things would go haywire if it weren't.

If you're on a 64 bit Windows, IIRC system32 is for 64bit DLLs. The 32bit ones should go into WOW64 folder. (But, I've no 64 bit Windows and I might be wrong, but that's what I remember)

Directory C:\WINDOWS\system32 is in the path, so it's irrelevant.
Title: lossyWAV 1.3.0 Development Thread
Post by: robert on 2010-06-03 09:52:52
Directory C:\WINDOWS\system32 is in the path, so it's irrelevant.


Quote
The operating system uses the %SystemRoot%\system32 directory for its 64-bit library and executable files. This is done for backward compatibility reasons, as many legacy applications are hardcoded to use that path. When executing 32-bit applications, WoW64 transparently redirects 32-bit DLLs to %SystemRoot%\SysWOW64, which contains 32-bit libraries and executables. 32-bit applications are generally not aware that they are running on a 64-bit operating system.

There are two "Program Files" directories, both visible to both 32-bit and 64-bit applications.


Quoted from http://en.wikipedia.org/wiki/WoW64 (http://en.wikipedia.org/wiki/WoW64)
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-03 10:05:35
Directory C:\WINDOWS\system32 is in the path, so it's irrelevant.


Quote
The operating system uses the %SystemRoot%\system32 directory for its 64-bit library and executable files. This is done for backward compatibility reasons, as many legacy applications are hardcoded to use that path. When executing 32-bit applications, WoW64 transparently redirects 32-bit DLLs to %SystemRoot%\SysWOW64, which contains 32-bit libraries and executables. 32-bit applications are generally not aware that they are running on a 64-bit operating system.

There are two "Program Files" directories, both visible to both 32-bit and 64-bit applications.


Quoted from http://en.wikipedia.org/wiki/WoW64 (http://en.wikipedia.org/wiki/WoW64)

That is done for backward compatibility reasons - if you put a 32-bit .dll in system32 it also works. I know, I've got 32-bit libraries in system32 and they work without any trouble.
Title: lossyWAV 1.3.0 Development Thread
Post by: robert on 2010-06-03 11:01:09
Hmmmm.... Baffled now - I have my copy of the DLLs in "C:\UserData\Bin" and have appended that directory permanently to the path using the method mentioned above.

.... but what this seems to mean is that recent testing is flawed as we are not sure that the DLLs have been used, and there is a bug when using the internal routines.

As I said, I'll get a fix out as soon as I can - though probably not tonight as it's my son's birthday today so we're all going out for dinner.

FYI, on my WinXP machine lossywav does find the libFFTW3-3.dll if present, the output files differ when the dll was found.

Code: [Select]
11:52:29,1659324	lossyWAV.exe	14872	QueryOpen	C:\dev\lossywav\libFFTW3-3.DLL	SUCCESS	CreationTime: 03.06.2010 11:05:19, LastAccessTime: 03.06.2010 11:52:22, LastWriteTime: 18.07.2009 07:08:10, ChangeTime: 03.06.2010 11:52:22, AllocationSize: 1.576.960, EndOfFile: 1.576.007, FileAttributes: A
11:52:29,1661517 lossyWAV.exe 14872 CreateFile C:\dev\lossywav\libFFTW3-3.DLL SUCCESS Desired Access: Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
11:52:29,1682698 lossyWAV.exe 14872 CreateFileMapping C:\dev\lossywav\libfftw3-3.dll SUCCESS SyncType: SyncTypeCreateSection, PageProtection: PAGE_EXECUTE
11:52:29,1682882 lossyWAV.exe 14872 QueryStandardInformationFile C:\dev\lossywav\libfftw3-3.dll SUCCESS AllocationSize: 1.576.960, EndOfFile: 1.576.007, NumberOfLinks: 1, DeletePending: False, Directory: False
11:52:29,1683061 lossyWAV.exe 14872 CreateFileMapping C:\dev\lossywav\libfftw3-3.dll SUCCESS SyncType: SyncTypeOther
11:52:29,1685210 lossyWAV.exe 14872 CreateFileMapping C:\dev\lossywav\libfftw3-3.dll SUCCESS SyncType: SyncTypeOther
11:52:29,1686866 lossyWAV.exe 14872 CloseFile C:\dev\lossywav\libfftw3-3.dll SUCCESS
11:52:29,1689900 lossyWAV.exe 14872 Load Image C:\dev\lossywav\libfftw3-3.dll SUCCESS Image Base: 0x70680000, Image Size: 0x155000
11:52:29,1690325 lossyWAV.exe 14872 ReadFile C:\dev\lossywav\libfftw3-3.dll SUCCESS Offset: 1.318.400, Length: 1.024, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
11:52:29,1692853 lossyWAV.exe 14872 ReadFile C:\dev\lossywav\libfftw3-3.dll SUCCESS Offset: 1.311.232, Length: 7.168, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
11:52:29,1694577 lossyWAV.exe 14872 RegOpenKey HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\libFFTW3-3.DLL NAME NOT FOUND Desired Access: Read
11:52:29,1695091 lossyWAV.exe 14872 ReadFile C:\dev\lossywav\libfftw3-3.dll SUCCESS Offset: 1.024, Length: 32.768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
11:52:29,1699552 lossyWAV.exe 14872 ReadFile C:\dev\lossywav\libfftw3-3.dll SUCCESS Offset: 1.180.672, Length: 31.232, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
11:52:29,1703955 lossyWAV.exe 14872 ReadFile C:\dev\lossywav\libfftw3-3.dll SUCCESS Offset: 1.294.848, Length: 16.384, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
11:52:29,1706844 lossyWAV.exe 14872 ReadFile C:\dev\lossywav\libfftw3-3.dll SUCCESS Offset: 1.211.904, Length: 1.024, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
11:52:29,2111253 lossyWAV.exe 14872 QueryOpen C:\cvs\do-it-again.wav SUCCESS CreationTime: 01.11.2008 22:57:21, LastAccessTime: 03.06.2010 11:51:23, LastWriteTime: 29.09.2007 13:19:26, ChangeTime: 18.04.2009 17:55:47, AllocationSize: 58.736.640, EndOfFile: 58.736.540, FileAttributes: A
11:52:29,2113602 lossyWAV.exe 14872 QueryOpen C:\dev\lossywav\do-it-again.lossy.wav NAME NOT FOUND
11:52:29,2185863 lossyWAV.exe 14872 CreateFile C:\cvs\do-it-again.wav SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
11:52:29,2204513 lossyWAV.exe 14872 ReadFile C:\cvs\do-it-again.wav SUCCESS Offset: 0, Length: 8
11:52:29,2206038 lossyWAV.exe 14872 ReadFile C:\cvs\do-it-again.wav SUCCESS Offset: 8, Length: 4
11:52:29,2207047 lossyWAV.exe 14872 ReadFile C:\cvs\do-it-again.wav SUCCESS Offset: 12, Length: 8
11:52:29,2208008 lossyWAV.exe 14872 ReadFile C:\cvs\do-it-again.wav SUCCESS Offset: 20, Length: 16
11:52:29,2208972 lossyWAV.exe 14872 ReadFile C:\cvs\do-it-again.wav SUCCESS Offset: 36, Length: 8
11:52:29,2211229 lossyWAV.exe 14872 ReadFile C:\cvs\do-it-again.wav SUCCESS Offset: 44, Length: 131.072
11:52:29,2215774 lossyWAV.exe 14872 CreateFile C:\dev\lossywav\do-it-again.lossy.wav SUCCESS Desired Access: Generic Read/Write, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Created
11:52:29,2219758 lossyWAV.exe 14872 CreateFile C:\dev\lossywav SUCCESS Desired Access: Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Open For Backup, Attributes: N, ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
11:52:29,2230522 lossyWAV.exe 14872 CloseFile C:\dev\lossywav SUCCESS
11:52:29,2255388 lossyWAV.exe 14872 WriteFile C:\dev\lossywav\do-it-again.lossy.wav SUCCESS Offset: 0, Length: 12
11:52:29,2257735 lossyWAV.exe 14872 WriteFile C:\dev\lossywav\do-it-again.lossy.wav FAST IO DISALLOWED Offset: 12, Length: 24
11:52:29,2259190 lossyWAV.exe 14872 WriteFile C:\dev\lossywav\do-it-again.lossy.wav SUCCESS Offset: 12, Length: 24
11:52:29,2260894 lossyWAV.exe 14872 WriteFile C:\dev\lossywav\do-it-again.lossy.wav FAST IO DISALLOWED Offset: 36, Length: 66
11:52:29,2262308 lossyWAV.exe 14872 WriteFile C:\dev\lossywav\do-it-again.lossy.wav SUCCESS Offset: 36, Length: 66
11:52:29,2264048 lossyWAV.exe 14872 WriteFile C:\dev\lossywav\do-it-again.lossy.wav FAST IO DISALLOWED Offset: 102, Length: 8
11:52:29,2265456 lossyWAV.exe 14872 WriteFile C:\dev\lossywav\do-it-again.lossy.wav SUCCESS Offset: 102, Length: 8
11:52:29,2874914 lossyWAV.exe 14872 ReadFile C:\cvs\do-it-again.wav SUCCESS Offset: 131.116, Length: 131.072
11:52:29,2895827 lossyWAV.exe 14872 WriteFile C:\dev\lossywav\do-it-again.lossy.wav FAST IO DISALLOWED Offset: 110, Length: 131.072
11:52:29,2897305 lossyWAV.exe 14872 WriteFile C:\dev\lossywav\do-it-again.lossy.wav SUCCESS Offset: 110, Length: 131.072

Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-03 12:27:22
Robert,

Thanks for that confirmation - I'll get onto bug-hunting soon....

Nick.

[edit] bug was so simple - calculating a real FFT without taking half of the number of samples - oops....

lossyWAV beta 1.2.2h attached to post #1 in this thread. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: robert on 2010-06-03 13:04:35
Nick, calling lossywav twice with the same input file, should it generate identical output files? If not, then my observation that it generated different output files is meaningless.

What can be seen from the above excerpt of ProcessMonitor log-text, lossywav finds libfftw3-3.dll and loads it too, but it seems to not use it:
%lossyWAV Warning% : libfftw3-3.dll not found, processing using internal FFT routines.


Title: lossyWAV 1.3.0 Development Thread
Post by: lvqcl on 2010-06-03 15:54:27
LossyWAV uses libfftw3-3.dll only if both libfftw3-3.dll and libfftw3f-3.dll are present.

(lossyWAV beta 1.2.2h).
Title: lossyWAV 1.3.0 Development Thread
Post by: robert on 2010-06-03 16:11:09
LossyWAV uses libfftw3-3.dll only if both libfftw3-3.dll and libfftw3f-3.dll are present.

(lossyWAV beta 1.2.2h).

Aha, OK.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-03 19:18:01
When lossyWAV starts, it checks for the existence of libfftw3-3.dll and libfftw3f-3.dll. If both are found then both are available. If no user preference is indicated then libfftw3-3.dll is used (double precision). If only libfftw3f-3.dll is found and no user preference is indicated then libfftw3f-3.dll is used (single precision). If neither are available or user preference is --fftw off then internal routines are used.

lossyWAV output should be identical for the same input data and parameters between multiple runs.
Title: lossyWAV 1.3.0 Development Thread
Post by: lvqcl on 2010-06-03 19:25:56
lossyWAV uses internal routines if only libfftw3-3.dll is available. When I tell it to use double precision with --fftw D option, the program reports:

Quote
%lossyWAV Warning% : libfftw3-3.dll not found, processing using internal FFT routines.

although libfftw3-3.dll is in the same folder. Only when both libfftw3-3.dll and libfftw3f-3.dll are present, lossyWAV uses libfftw3-3.dll.
Title: lossyWAV 1.3.0 Development Thread
Post by: robert on 2010-06-03 19:39:24
When lossyWAV starts, it checks for the existence of libfftw3-3.dll and libfftw3f-3.dll. If both are found then both are available. If no user preference is indicated then libfftw3-3.dll is used (double precision). If only libfftw3f-3.dll is found and no user preference is indicated then libfftw3f-3.dll is used (single precision). If neither are available or user preference is --fftw off then internal routines are used.

lossyWAV output should be identical for the same input data and parameters between multiple runs.

Well, in my case I had only libfftw3-3.dll in search path. In this case libfftw3-3.dll wasn't used at all, neither implicit nor explicit.

My WinMerge always tells me there is a difference in the binary files. I found out, the output contains a timestamp, which is different on the second run, naturally.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-03 19:42:58
Thanks again - something wrong, I think - I'll get back to bug-hunting....
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-03 21:46:26
Only when both libfftw3-3.dll and libfftw3f-3.dll are present, lossyWAV uses libfftw3-3.dll.

That's a silly bug, but I can't say that something similar hasn't happened to me a couple of times when I wrote programs. 

I confirm - when both libfftw3-3.dll and libfftw3f-3.dll are present, lossyWAV reports "[D]" under results if no -F or --fftw preference is given, otherwise it reports "".
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-03 21:54:45
There's something strange about the noise added to "wheeee" with -Z -A in the latest version. Look at the waveform of the right channel of wheeee.lwcdf.wav at 5.43 seconds. That definitely seems to be too much noise:

(http://img707.imageshack.us/img707/8817/122gstrangenoise.png)


I will see if I can hear the difference at that spot between the original and lossy wheeee.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-03 21:58:56
I think that I have cracked the logic for use of whichever FFT routines....

lossyWAV beta 1.2.2i attached to post #1 in this thread.

[edit] Well spotted - it looks like it may be one of the clicks talked about earlier - I will see if I can eradicate it.... [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-03 22:12:20
A distinct click can easily be heard at 5.43 seconds in the right channel of wheeee.lossy.wav with -Z -A which is not present in the original, so it's not just a visual oddity when looking at the waveform.


edit:
Quote
[edit] Well spotted - it looks like it may be one of the clicks talked about earlier - I will see if I can eradicate it.... [/edit]

We're such a nice little machine, aren't we?
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-04 00:58:18
I've made another sample, similar to "wheeee" but distinctly different, and this one exhibits two clicks similar to the one that happens in wheeee. Here it is, this one is aptly named "zweee" (what can I say - I'm talented for giving them appropriate names):

- Zweee (http://www.speedyshare.com/files/22782345/download/zweee.flac)

This time the clicks are on the left channel, one at 1.13 seconds and the other at 2.9 seconds.

Indeed, this time the clicks are much more difficult to hear in the lossy sample but looking at the added noise (zweee.lwcdf.wav) it's apparent that something is obviously wrong:

(http://img401.imageshack.us/img401/3483/clicksinnoise.png)

(http://img338.imageshack.us/img338/703/clickone.png)

(http://img514.imageshack.us/img514/9707/clicktwo.png)

They're even clearly visible when you compare the waveforms of zweee.wav and zweee.lossy.wav:

(http://img46.imageshack.us/img46/6987/zweeespectrum.png)

(http://img88.imageshack.us/img88/7610/zweeelossyspectrum.png)


Nick, maybe you could see what is common in these three spots - right channel of "wheeee" at 5.43 seconds and left channel of "zweee" at 1.13 and 2.9 seconds, maybe there's something common in the spectrums or something else at these three spots that makes lossyWAV bug out and produce clicks like these.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-04 06:26:54
Thanks for this sample - I will, as you suggest, use it to fault find.

The error looks like filter instability - I need to work out what conditions that occurs under.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-04 07:10:21
Glad I can help!

Also, there's another thing that's odd for me about this new sample, more specifically about the noise lossyWAV adds to it (at least with -Z -A), and that's that there appears to be absolutely no noise added at all (or extremely little) in the places where, judging by the original signal, there definitely should have been noise added. For example, check out the noise at 0.62, 1.6, 3.42 and 4.38 seconds - nearly no noise added in both channels, yet the original signal doesn't seem to be any quieter at those places and the noise floor appears to be just as high as elsewhere.
Title: lossyWAV 1.3.0 Development Thread
Post by: SebastianG on 2010-06-04 16:59:47
The error looks like filter instability

I agree.

I need to work out what conditions that occurs under.

One aspect is numerical accuracy. You should probably use doubles (if you're not doing this already) for the filter design code. I'm not sure if it's worth using double floats for the actual filter, though. But the most important aspect is the shape you want the filter to match. It should be rather smooth and not too steep.

Cheers!
SG
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-04 18:48:37
Thanks for the confirmation, SG. I am using doubles throughout - however, I am not checking the desired shape of the filter at all, although it is modified (-3dB <1kHz; -1dB >6kHz; interpolated between 1kHz and 6kHz). I have worked out a temporary fix by only feeding part (>80%) of the "quantization error" into the WAPL_Update function - this seems to work for the two samples provided by doccolinni.

lossyWAV beta 1.2.2j attached to post #1 in this thread.

[edit] Spectrograms and sample plots removed. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-04 19:20:41
lossyWAV beta 1.2.2j attached to post #1 in this thread.

Nice, I'm going to try it out later this evening.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-04 23:20:27
I tried furious again using 1.2.2.j -Z --adaptive.
Hiss is still there, and there are click-like sounds added.

I will try different --adaptive parameters hopefully on sunday.
Title: lossyWAV 1.3.0 Development Thread
Post by: SebastianG on 2010-06-05 12:26:50
I have worked out a temporary fix by only feeding part (>80%) of the "quantization error" into the WAPL_Update function - this seems to work for the two samples provided by doccolinni.

I actually have no idea what this quick fix does. It may work in this case and be worse in others. You alter the shape by this in a way I can't easily predict. IMHO, you should generate better curves in the first place instead of feeding "bad" curves to the filter design routines and messing with the noise shaping loop. The noise shaper is not the problem. The input to the filter design routines is.

You should partition the spectrum into non-uniform subbands (for example, starting with bandwidths of 100Hz and increasing bandwidths up to 1000Hz for higher frequencies) compute tolerable noise levels in dB for each of these subbands based on the signal's power and "tonality" in those areas. As a first approximation you can use fixed SNRs depending on the frequency ranging from 40 dB (lower frequencies) to 10 dB (above 6 kHz). Make sure that the levels between neighbouring bands don't differ too much (i.e. differences restricted to +/- 15 dB). In order to do this you might have to decrease some noise levels. Keep in mind that 0dB corresponds to the noise level of rectangular quantization noise with +/- 1/2 LSBs. So, going below, say, -20 dB hardly makes sense. Interpolate those resulting data points smoothly (for example, with a 2nd order B-Spline as "interpolator").

How do you currently determine the "bits_to_remove" value?

Cheers!
SG
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-05 12:55:15
I agree that the "desired shape" used at present is to blame - probably too steep, as you said earlier.

The signal is analysed using an FFT the same length as the codec block to produce the "desired shape" at present. This is 512 samples for 44.1/48kHz signal, giving a bin resolution of approx. 86Hz. I have an idea how to compute power (from one of your e-mails) but for tonality I do not know.

I will try to start on calculating power for varying bandwidths (for every bin?) and see where that gets to.

The determination of bits-to-remove has not changed - I remember you saying that the make_filter routine determines this (gain?) but it was much lower than the value determined using the existing method and was not used. Maybe this could be used totally separately (i.e. no other FFT analyses of the signal) to determine bits-to-remove, but then it wouldn't be lossyWAV as we know it.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-06 01:47:03
The determination of bits-to-remove has not changed - I remember you saying that the make_filter routine determines this (gain?) but it was much lower than the value determined using the existing method and was not used. Maybe this could be used totally separately (i.e. no other FFT analyses of the signal) to determine bits-to-remove, but then it wouldn't be lossyWAV as we know it.

In that case maybe it's the algorithm determining bits_to_remove somehow interfering with the algorithm determining noise shaping/filtering? I mean, if the make_filter algorithm determining the noise shaping/filtering makes such calculations which produce lower values for bits_to_remove then if you increase the value of bits_to_remove (which the old algorithm does) maybe in some rare cases (as in the samples I provided) the noise shaping/filtering won't produce the desired result precisely because more bits were removed than for what the noise shaping/filtering produced by make_filter was intended?

I don't know if any of that made sense.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-06 10:26:44
I tried 1.2.2.j -Z --adaptive default, 64, and 128 with furious.
Worst part of the 1.2.2.j encodings is from second 1.9 to 2.7: click-like artefacts and hiss.

--adaptive 64 improves upon the kind of clicks compared to --adaptive default, but makes hiss worse.
--adaptive 128 is similar, but I prefer --adaptive 64.

Looking at the error file for second 1.9 to 2.7, the error has a strange block structure in the spectogram.

While -z --adaptive is fine for tuning purposes, probably it uses too low a bitrate.
So I also tried -Z --adaptive 64 --altpreset. The strange artefacts are gone for me, but the hiss is still ABXable though not that easy as before.
-Z --adaptive --altpreset is better for me as the hiss has lower volume, but the last second is still not very hard to ABX.

For a comparison I also listened to the non-adaptive variant -Z --altpreset. I'm sorry to say that at the moment --adaptive doesn't improve upon the result of this.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-06 21:30:24
Thanks again for your listening efforts - I have taken onboard SG's comments and will attempt to implement it over the next few days.
Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2010-06-08 12:14:49
IMHO, you should generate better curves in the first place instead of feeding "bad" curves to the filter design routines and messing with the noise shaping loop.
Yes!

Quote
You should partition the spectrum into non-uniform subbands (for example, starting with bandwidths of 100Hz and increasing bandwidths up to 1000Hz for higher frequencies) compute tolerable noise levels in dB for each of these subbands based on the signal's power and "tonality" in those areas. As a first approximation you can use fixed SNRs depending on the frequency ranging from 40 dB (lower frequencies) to 10 dB (above 6 kHz). Make sure that the levels between neighbouring bands don't differ too much (i.e. differences restricted to +/- 15 dB). In order to do this you might have to decrease some noise levels. Keep in mind that 0dB corresponds to the noise level of rectangular quantization noise with +/- 1/2 LSBs. So, going below, say, -20 dB hardly makes sense. Interpolate those resulting data points smoothly (for example, with a 2nd order B-Spline as "interpolator").
To be really clear, IMO (please correct me if I'm wrong here SebG), what SebG is talking about is how to get the thing working - not how to do a really good job.

With all this work, you'll have a 1980s style psychoacoustic model, which is then crippled.

I think a better way would be to offer the user 3 or 4 options (at least while beta testing):
1. no noise shaping
2. fixed noise shaping
3. dynamic noise shaping, conservative (not psy based)
4. dynamic noise shaping, aggressive (based on best psy model you can find)

If you're going to have one noise shaping filter per block (and that seems like a good start), then for a conservative approach I think you could try keeping the previous approach of using multiple FFT sizes to determine the lowest signal level in the block. For each frequency, use the lowest value found in that block across the various FFT sizes (with the scaling that was there already, and the many successful refinements that you added). Then smooth that target function, bringing the peaks down (not raising the troughs up). The bits you can remove is defined by the area under that target function.

I think any "proper" psy model should also be post-processed in this way, finding the lowest allowed noise level in each frequency band in each block, and smoothing the resulting target function so the filter is realisable and stable.


Going further, you could have multiple (successive) target filters in each lossyWAV block (though obviously only one bits_to_remove value - unless you communicate varying block size to the encoder!). Multiple target filters in one block would bring an advantage in a signal where the spectrum shape changed a lot within one block (different filter required) while the area under the spectrum didn't change much (same bits to remove required), but it wouldn't help much otherwise.

Hope this helps. Your hard work and tenacity is amazing!

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: SebastianG on 2010-06-08 16:56:14
To be really clear, IMO (please correct me if I'm wrong here SebG), what SebG is talking about is how to get the thing working - not how to do a really good job.

My suggestion was intended to be both.  The part with fixed, frequency-dependent SNRs was about getting it to work and could be replaced with more elaborate approaches. The stuff about grouping frequencies to bands, estimating tolerable noise levels is what every psychoacoustic model does unless I'm mistaken. The part about keeping the target filter's frequency response smooth still applies to more sophisticated psychoacoustic models.

If you're going to have one noise shaping filter per block (and that seems like a good start), then for a conservative approach I think you could try keeping the previous approach of using multiple FFT sizes to determine the lowest signal level in the block.

You mean the lowest level within a certain frequency region, right? Otherwise, I don't see where you'd need noise shaping for in this case.

[...] Then smooth that target function, bringing the peaks down (not raising the troughs up). The bits you can remove is defined by the area under that target function.

Right. The code I wrote even computes this "noise_gain" where log2(noise_gain) = bits_to_remove. This is sort of a by-product of the filter design computation.

I think any "proper" psy model should also be post-processed in this way, finding the lowest allowed noise level in each frequency band in each block, and smoothing the resulting target function so the filter is realisable and stable.

Yes. Well, "proper" models are expected to produce reasonably smooth "masking" curves due to the spreading function. Apart from "smoothness" another constraint is: Keep the noise PSD target below the signal's PSD (at least by, say, 9 dB). This ensures two things:


Going further, you could have multiple (successive) target filters in each lossyWAV block (though obviously only one bits_to_remove value - unless you communicate varying block size to the encoder!). Multiple target filters in one block would bring an advantage in a signal where the spectrum shape changed a lot within one block (different filter required) while the area under the spectrum didn't change much (same bits to remove required), but it wouldn't help much otherwise.

Yes. This noise PSD target should probably be smoothly interpolated over time to reduce artefacts due to the otherwise "hard" switching from one filter to another.

Cheers!
SG
Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2010-06-08 17:46:11
I wonder if the effort to interpolate IIR filters properly is worth it in this case? Do you know of some neat tricks?

As far as I can tell, the hard switch doesn't cause any artefact that breaches the upper spectral bounds of both filters. So while it's not ideal, the output remains within the bounds set by whatever model created the target filter responses.

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: SebastianG on 2010-06-09 16:40:25
I don't know if it's necessary and/or overkill. But the idea of a slowly changing filter as opposed to one that switches from block to block is appealing.

The easiest way this can be done is by smoothly adapting the target curve and feeding it to the filter design routines more than once per block. That's it. There's no need to "interpolate filter coefficients". Although, this would be possible as well. The speech coding community has some experience with this (interpolation of LAR (http://en.wikipedia.org/wiki/Log_area_ratio) or LSF (http://en.wikipedia.org/wiki/Line_spectral_pairs) coefficients). But in case of lossyWAV there's no need to add complicated code for interpolating filter parameters. One can invoke the filter design a couple of times with a slowly changing (over time) target curve and be done...

Cheers!
SG
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-09 21:24:44
I have made some headway regarding the implementation of the varying bin width power spectrum - but if I add +ve and -ve frequencies in the way that you suggested earlier then I get a symmetry about N/4 in the power spectrum - how is that used to create the desired shape for the filter?

Reading David and your most recent comments, it seems that 1 x 512 sample FFT > results > power spectrum > desired shape > filter is not the best way to go - maybe it should be 4 x 128 sample FFT and gradual transition of the desired shape? Should these FFT analyses overlap? I take it that the desired shape from the previous block for that channel should be taken into account.

Food for thought - and a direction in which to develop the code.
Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2010-06-10 08:49:52
IMO you should take account of the 512 sample FFT and the 128 sample FFTs, just like you did before. It's a conservative approach.

Also IMO you should "just" grab the psy model from musepack or similar.

@SebG - yes, tried that (intermediate filters from intermediate target response) - of course it works, but it's just a series of smaller discrete blocks, rather than something that really changes smoothly. It didn't seem to be worth it. But then I was playing in MATLAB so it was all very slow, hence "worth it" might be a different threshold in real code.

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: moozooh on 2010-06-10 14:05:41
Also IMO you should "just" grab the psy model from musepack or similar.


What would be the practical reason between using a Musepack-based-processed FLAC encode and, say, a Musepack --braindead encode? The bitrates should be roughly similar, and I imagine there will be some minorly adverse effects for transcoding to another lossy format either way.
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2010-06-10 16:16:06
Also IMO you should "just" grab the psy model from musepack or similar.

Although the Musepack psychoacoustic model was very effective, the comments from developers at the time, were that it wasn't very portable. Maybe something can be reverse engineered? OTOH maybe a much simpler model (without Clear Voice Detection) would suffice.
Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2010-06-10 18:36:34
What would be the practical reason between using a Musepack-based-processed FLAC encode and, say, a Musepack --braindead encode?
What's the practical reason to use lossyWAV at all?

Your DAP plays FLACs?
You have more confidence in FLAC (or whatever)'s longevity?
You don't want to use quite so much space as lossless?
You like the potential for fast lossless efficient transcoding to most other lossless formats?
Fun?

Quote
The bitrates should be roughly similar
I bet they're not - I bet lossyWAV would be higher - but maybe we'll see.

Quote
and I imagine there will be some minorly adverse effects for transcoding to another lossy format either way.
Maybe. Again, hopefully we'll see.

You can do pretty much any shaping you want with lossyWAV. You probably can with Musepack too (same potential "issue" - at worst you need to throw lots of bits at it to get exactly what you want) - though with Musepack you're stuck with a filterbank which causes problems (or is inefficient) with some signals (though should be a benefit on average overall - massively so).

Anyway, it was only an exactly. There are other decent psy models out there. What I was trying to say was: no point coding one from scratch. No point coding one at all unless you want to!

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: moozooh on 2010-06-10 19:10:26
 
What's the practical reason to use lossyWAV at all?

Your DAP plays FLACs?
You have more confidence in FLAC (or whatever)'s longevity?
You don't want to use quite so much space as lossless?
You like the potential for fast lossless efficient transcoding to most other lossless formats?
Fun?

I apologize, I just realized I said "reason" while I actually meant "difference". For instance, from my personal standpoint, both LossyFLAC -q7 to -q10 and Musepack -q7 to -q10 are:

— decoded by my DAP with equal efficiency;

— by definition, lossy;

— supposed to be completely transparent (I understand that exceptions do occur);

— supposed to be relatively good for transcoding as far as lossy material goes.

As you see, there is very little (if any) practical difference for me, or probably anybody else who uses Rockbox on their DAP and/or a decent software player on their PC.

I take it that the reason you suggested taking an existing psy-model for LossyWAV is avoiding duplication of effort. That's understandable. But in order to avoid further duplication of effort, I believe LossyWAV's adaptive noise-shaping/psymodel research priority should be second-generation transparency in processed-to-lossy transcoding, unlike Musepack's first-generation transparency in listening. Since Musepack was never designed for transcoding, I'm sure it's possible to outperform it in that department by making LossyWAV's output friendlier to lossy codecs, and thus increase the transparency of transcoded material beyond that of Musepack.

What do you think?

Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2010-06-11 11:35:16
...in order to avoid further duplication of effort, I believe LossyWAV's adaptive noise-shaping/psymodel research priority should be second-generation transparency in processed-to-lossy transcoding, unlike Musepack's first-generation transparency in listening.
That's an interesting idea. I'm not sure it's possible. I was going to suggest a conservative "non-psy" based approach to be safer with potential/unknown future transcoding. Either way, it's a bit of a vague / unknown / unpredictable target to hit.

I think the psy based approach should at least target first generation transparency first. I don't think even that is going to be simple. Just because you import a psy model doesn't mean it will work! e.g. the format the psy model was original designed for will be restricted in the kind of artefacts it can add, hence the psy model may not be defensive against the kind of artefacts which the original format can't possibly add.

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: sauvage78 on 2010-06-11 12:59:59
I disagree, lossywav is just a lossy codec that doesn't have some flaws of classic lossy codecs.
Its advantages are tied to the use of lossless codecs:
- potential broader hardware support & future proof hardware support.
- 100% safe gaplessness (for exemple, despite its audio quality, Nero AAC is not 100% safe regarding gaps with some tag editors. I tested with MP3tag, but it's likely true with even more obscure tag editors)
- the ability to split & join losslessly (no classic lossy codec can do that due to breaking gaps, I tested with vorbis & nero aac, I dunno & don't care for musepack)
- the above make lossywav the only lossy codec usable as CDImage+cue.

This means that transparency & bitrate is not everything in audio. Nero AAC is the best audio codec regarding the transparency point, but personnaly there is no way I would use it for CD encoding due to its non-native gaplessness implementation (I only use it for Video, as I use x264 & don't want to mix norms). The additionnal features of audio codecs are very important to make it handy for the end user.

What this means is that the main advantage of lossywav is not its audio quality, but some added flexibility in some particular uses. It doesn't mean that lowering the transparency point is useless, but it certainly means that comparing lossywav transparency point to classic lossy codecs is pointless. If you give it the right bitrate lossywav does achieve the same & even a better quality than classic lossy codecs by being more robust. (So far Lossywav is unaffected by many classic killer samples, particulary applauds in live performance)

The conclusion is that if your not ready to give up some bitrate for some flexibility, then you should not use lossywav.
If you think Musepack is more handy than lossywav, just use Musepack.

Also I completely disagree with the theorical myth that lossywav would be suited for further transcoding with classic lossy codecs, this might be true but there is no real evidence of this. Furthermore it likely highly rely on which lossywav setting you used prior doing further transcoding. If you used lossywav near its transparency point as the first encode, I personnaly highly doubt that you can transcode it a second time with a classic lossy codec & get an as good result as if it were a first classic lossy encode. All this is very theoric & untested, but what this means to me, is that because nobody really knows how lossywav react to transcoding (except for saying very vague statements like "the higher is the quality of the source the better will be the transcoding"), optimizing it for this use is insane.

Last time I tested lossywav, a transparent encode was minimum ~380Kbps, any classic lossy codec at this bitrate is not particular bad at transcoding too ... so thinking that lossywav would be better for transcoding due to a theoric advantage is a missundertanding of why transcoding is bad: transcoding is crap due to multiple generation loss. If you cannot ABX this generation loss for 1 generation loss then this advantage is ZERO. What is the use of a theoric non-ABXable benefit ? Transcode even more ? You're kidding, with many generation loss, transcoding lossy to lossy is crap, no matter if the source is lossywav. So if lossywav is theorically more suited for transcoding than other classic lossy codecs, then great, but I want lossywav to be a first class lossy codec first, no matter if it lowers its theoric "transcodability".
Title: lossyWAV 1.3.0 Development Thread
Post by: Enig123 on 2010-06-11 13:34:10
LossyWAV is a totally new stuff that always makes me re-think of the definition of "lossy". It can explorer the use of psychaoustic model in a new way far different from traditional lossy codecs. Really excited to see how far it can go.
Title: lossyWAV 1.3.0 Development Thread
Post by: SebastianG on 2010-06-11 13:35:48
lossywav […]
Its advantages are tied to the use of lossless codecs:
- potential broader hardware support & future proof hardware support.
- 100% safe gaplessness (for exemple, despite its audio quality, Nero AAC is not 100% safe regarding gaps with some tag editors. I tested with MP3tag, but it's likely true with even more obscure tag editors)
- the ability to split & join losslessly (no classic lossy codec can do that due to breaking gaps, I tested with vorbis & nero aac, I dunno & don't care for musepack)
- the above make lossywav the only lossy codec usable as CDImage+cue.

- "hybrid" mode ("correction file")

This means that transparency & bitrate is not everything in audio.

Glad to hear that. I think i needed to be reminded of this.

Although, MP3 (via LAME tag) and Vorbis (to my knowledge) support accurate and gapless splitting & rejoining. It's just that nobody has implemented tools for that yet. But the formats allow this.

[…]
The conclusion is that if your not ready to give up some bitrate for some flexibility, then you should not use lossywav.

I guesstimate the difference would be around 60kbit/s at similar quality levels and comparable psychoacoustic models. Obviously, it's not suited for very low bitrates but I think it scales nicely in the higher bitrate area and might be an option if you need a large noise/masking headroom for the warm fuzzy feeling in your tummy or just because you plan to further process the file while still saving some disk space.

Cheers!
SG
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-11 22:06:42
I've been working on the adaptive shaping algorithm and have introduced a mechanism whereby the desired-shape changes gradually rather than totally every codec-block.

lossyWAV beta 1.2.2k attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-11 22:36:11
I've been working on the adaptive shaping algorithm and have introduced a mechanism whereby the desired-shape changes gradually rather than totally every codec-block.

lossyWAV beta 1.2.2k attached to post #1 in this thread.

Great! I've been a bit overwhelmed with various things lately so I apologise for not doing any testing in the last couple of days, but hopefully I'll manage to do some tests tonight.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-11 23:56:48
Just looking at some spectrograms, it looks as if lossyWAV 1.2.2k due to the new smooth noise shaping achieves rudimentary temporal post-masking, which is actually not unexpected at all because of the nature of this new kind of noise shaping wherein the signal from previous block affects the current block's noise shaping.

Whether the temporal post-masking was the intended goal behind the idea of smooth noise shaping or not I do not know, but it certainly is a nice by-product if it wasn't.
Title: lossyWAV 1.3.0 Development Thread
Post by: collector on 2010-06-12 10:46:26
Also I completely disagree with the theorical myth that lossywav would be suited for further transcoding with classic lossy codecs, this might be true but there is no real evidence of this. Furthermore it likely highly rely on which lossywav setting you used prior doing further transcoding. If you used lossywav near its transparency point as the first encode, I personnaly highly doubt that you can transcode it a second time with a classic lossy codec & get an as good result

In the far beginning of the development it was stated q7.5 and above, or -E and above are suitable to used as a source for lossy encoding. I think that this still is a fact. Although recent tests try to prove that even q3 and lower provide transparency; while meant for portable use, in noise environments. But maybe it's my hairdo, mood or English that I don't see a problem ?

My lossyflacs q8 and even q6 to lossy mp3 V1 are suitable enough for my dap (well, my wife's Sansa Clip).
Title: lossyWAV 1.3.0 Development Thread
Post by: sauvage78 on 2010-06-12 11:54:54
collector:
Sure old -q7.5 & -q5 can suffer a classic lossy generation loss without being distinguishable from pure lossless as a source, the safety margin here is large enougth. What I am saying is that I doubt that you can say the same for old -q2.5, because here there is almost no margin.

Now look at people signature:
Nick.C:
lossyWAV -P -t|FLAC -5: 378kbps
halb27:
RG | lossyWAV -q 3.5 --altpreset | FLAC -8 (409 kbps)

... myself, I didn't test lossywav recently because I can offer lossless, but I know that when I will come back to it, I will use something near the old portable setting.

Most people who use lossywav, seems to use it just like classic lossy: near its transparency point, so taking in account "transcodability" as a main argument for development is IMHO non-sense. The fact that -q7.5 & -q5 are easyly transcodable is nice, but it is not the main feature of lossywav according to me. Keeping compatibility with "transcodability" should IMHO not be something that prevents lowering the transparency point of lossywav.

For me "transcodability" is a nice side effect of the used technology of lossywav. Not a main feature.

I do not pretend to teach people how to use their files, but I am clearly saying that using -q2.5 for further transcoding to DCT codecs is a naive miss-use, ... if you use something slightly higher (I dunno say -q5), then I agree that transcoding would likely be unABXable from a pure lossless source. Personnaly, I just don't use lossywav for this feature, hence I don't really care for it.

I am not saying that there is no clever use of it for some people, I am just saying that it is such an unusual way of using audio that it should not hinder the development of more classic use of lossywav. (Like high quality lossy files for DAP supporting flac)

If at some point Nick.C must adopt some technology that make lossywav unsuited for transcoding, don't blame him for doing so, just ask for a special transcoding setting.
Title: lossyWAV 1.3.0 Development Thread
Post by: shadowking on 2010-06-12 12:37:45
I disagree.  You can use lower than a true transparency setting and still have un-abxable or near transparent transcoding . Its already being documented and tested . Read old wavpack articles by Den , myself , Guruboolez 350 ~ 400k tests and my recent tests showed losswav perform well even @ Q1.5 for transcoding. In fact the more you get into noise shaping and traditional psy stuff the more such things start to fall apart in my experience.
Title: lossyWAV 1.3.0 Development Thread
Post by: sauvage78 on 2010-06-12 13:59:13
Lossywav -q1.5 with further DCT transcoding transparent on Abfahrt Hinwil, Fool's Garden & Therion samples, when lossywav -q2 alone is already not transparent on these samples (I have posted plenty of ABXing logs that shows the weakness of lossywav on these samples below -q2.5 with old lossywav versions) ??? It's either lossywav has improved a lot since last time I tested it, or you're kidding me. Anyway I don't want to argue about listening tests (obviously you didn't listened the right samples), I actually don't plan to waste some time to prove my claims, so nevermind you're right (I am not joking you're probably right for yourself with the samples you tested, first I don't know about wavpack lossy I never tested it & then I admit I don't know how lossywav has evolved recently). I strongly encourage everybody to not trust anyone blindly (neither me or you, & even with valid ABXing logs because the choice of samples/earing skills/health(spleep, listening fatigue)/hardware ... can affect the possible conclusions a lot) & test for themselves.

Edit:
If you're arguing that you can transcode lossywav to another classic lossy codec without any additionnal loss due to this cross-codec transcoding itself (& not due to the original or target codecs/settings used whatever they may be). I highly doubt that any published test would be valid on a large scale. From a theoric point of view it is assumed that some of the cross-codec transcoding possible loss overlaps, but from a real life listening tests point of view, the truth is nobody knows if there is not some nasty unexpected side affects.
Title: lossyWAV 1.3.0 Development Thread
Post by: shadowking on 2010-06-12 15:21:00
I'm not talking about perceptual transparency. I mean transcoding quality. Artifacts from transcoding have little to do if LW is transparent or not. If LW is not transparent on a sample you may hear the same artifact on the transcode - that is not a transcoding artifact. A transcoding artifact is an extra effect added not present in the original wav or LW file .
Title: lossyWAV 1.3.0 Development Thread
Post by: carpman on 2010-06-12 15:42:27
Surely there's no real argument here.
People who use lossywav as a lossless replacement (me for example) use a high setting so they can transcode; people who use it as a lossy replacement (Nick & halb27) will use a setting close to perceptual transparency where transcoding may be an issue, but since they're using instead of other traditional lossy codecs, they won't have the need to transcode.

As long as lossywav offers both, and presumably all this noise shaping stuff is only going to be for below a certain setting, then there's no transcode issue.

C.
Title: lossyWAV 1.3.0 Development Thread
Post by: sauvage78 on 2010-06-12 15:58:51
So I am not denying that the generation loss of lossywav to lossywav is likely smaller than DCT to DCT & so that lossywav to DCT is likely less agressive than DCT to DCT. What I am pointing out is that this generation loss exist even if smaller, & that using lossywav near its transparency point as a source for further DCT encoding, you're playing with your luck & risking to have both lossywav & DCT artefacts in the final encode ... with the possibility of a third artefact due to cross-transcoding randomness (Travelling unknown ground). So the theoric "transcodability" of lossywav depends on so many factors & trying to improve it is insane. Furthermore selling lossywav to newbies as a transcodable codec in all situation is not true too.

Saying that lossywav is less agressive than DCT is true, saying that lossywav is suited for transcoding is arguable because it depends on how you use lossywav & to what you're comparing it too.

A transcoding between Nero AAC 320Kbps VBR to Nero AAC 192Kbps VBR is likely to be transparent too (I dunno I never tested but I would assume so), does this make Nero AAC suited for transcoding ? I don't think so.

The supposed "transcodability" of lossywav depends on how many generation loss you're willing to suffer, & as 99% of people will not suffer more than 1 transcoding, Nero AAC 320Kbps VBR is not less suited than lossywav -q5 for transcoding if you will only do 1 additionnal transcoding. Nero 320Kbps or lossywav -q5 as the source it doesn't matter, because a single generation loss is likely to not be ABXable. (Edit: Big typo here)

What this means is that people who use lossywav only for this supposed better transcodability are fooling themselves with something like "a warm & fuzzy" audiophile feeling.

Not that they are completely wrong (With more than 1 generation loss they are probably right), but they must know the limit in real life of this theoric benefit. Once they will understand this limit they will likely understand that keeping this virtual gain shouldn't hinder lossywav normal development as a lossy codec. It isn't worth it.

Edit:
I completely agree with carpman, there seems to be two schools of lossywav users:
1:Lossless(on PC)+Lossywav(on DAP)
2:Lossywav(on PC)+Classic lossy(on DAP)
The first school seems to consider lossywav as a lossy codec of its own, the second as a lossless replacement, that's why if ever Nick dives into the realm of real lossy codecs technology, I asked for a "transcoding setting" for this kind of users, so that the two use of lossywav doesn't conflict together.

Edit2: Fixed a big typo ... & plenty of small  Sorry.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-14 11:09:43
My test with 1.2.2.k unfortunately did not show up improvements for furious. Artefacts are very audible.
Title: lossyWAV 1.3.0 Development Thread
Post by: collector on 2010-06-14 13:20:45
collector:
Sure old -q7.5 & -q5 can suffer a classic lossy generation loss without being distinguishable from pure lossless as a source, the safety margin here is large enougth. What I am saying is that I doubt that you can say the same for old -q2.5, because here there is almost no margin.

My not so old version 1.2.0 still states -E > 'high quality, also suitable for transcoding' and I do agree with that. So my lossyflac -q8 images provide a good source for my transcoded tracks, mp3 V2 (for the wife's Sansa Clip). That's it.
Transcodes are to mp3, not to lossyflac -P because the mp3's are much smaller. Artifacts ? Why bother. The Clip is used in trains, stations and other noisy environments.

Quote
For me "transcodability" is a nice side effect of the used technology of lossywav. Not a main feature.

Agreed. I mainly use -q8 for classical and -q6 for the rest, being blues rock and pop.
Title: lossyWAV 1.3.0 Development Thread
Post by: collector on 2010-06-14 13:41:45
.... So the theoric "transcodability" of lossywav depends on so many factors & trying to improve it is insane. Furthermore selling lossywav to newbies as a transcodable codec in all situation is not true too.

I think lossyWav isn't sold to be a transcodable codec in ALL situations. Only -I and -E (-q10 down to -q7.5) are mentioned. And I think that's right. And off course, the newbies are responsible for their own conversions, transcodings and ABXing.

I won't discuss transcoding from whatever low lossyflac setting to whatever low lossy setting here, since I don's use lower than -q6. Lower than this I think transcoding must be tested properly by a testpanel.
Title: lossyWAV 1.3.0 Development Thread
Post by: moozooh on 2010-06-16 20:50:54
The conclusion is that if your not ready to give up some bitrate for some flexibility, then you should not use lossywav.
If you think Musepack is more handy than lossywav, just use Musepack.


I'm not sure what you're disagreeing with, but if you're referring to me as the only (I think) person who has mentioned using Musepack on this page, I never intended them to compete. My point was exactly opposite, in fact!

Also I completely disagree with the theorical myth that lossywav would be suited for further transcoding with classic lossy codecs, this might be true but there is no real evidence of this. Furthermore it likely highly rely on which lossywav setting you used prior doing further transcoding. If you used lossywav near its transparency point as the first encode, I personnaly highly doubt that you can transcode it a second time with a classic lossy codec & get an as good result as if it were a first classic lossy encode. All this is very theoric & untested, but what this means to me, is that because nobody really knows how lossywav react to transcoding (except for saying very vague statements like "the higher is the quality of the source the better will be the transcoding"), optimizing it for this use is insane.



Myth? I proposed it as a goal for people who are looking at LossyWAV as a possible replacement of lossless codecs. (That's disregarding the fact that such feature is directly advertised in the settings.)

There aren't that many differences in general principles by which popular lossy codecs operate; it might be possible to account for some of them at least in regards to how they process data. In other words, not using noise-shaping/masking algorithms that are prone to introducing additional difficulties for lossy codecs, at least on switches intended for stable first-generation transparency and not portable or high-compression use.

Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-17 20:53:17
lossyWAV beta 1.2.2m attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-17 21:26:22
I tested 1.2.2.m with furious.
-Z --adaptive is better IMO than with the recent versions, however hiss and artefacts are pretty audible.
But I guess this setting uses a bitrate which possibly will never be fine for problematic samples so I also tried -Z --adaptive --altpreset.
Result is good. I can't hear an artefact. Within second 1.8 to 2.7 I think I can hear a tiny amount of hiss, but ABXing lead only to 7/10.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-17 21:49:43
Thanks for the v.fast response (and taking the trouble to ABX yet again  ) - I was beginning to think that Furious may never be transparent at -Z -A - your results give some support to that opinion. Taking into account that -Z -A -t will result in fewer bits-removed than -Z -A, (333kbps resultant FLAC rather than 266kbps, in this case) as it is roughly equivalent to -q 1.685 -A --limit 15159, it would be interesting to know your opinion of Furious at -q 1.5 -A.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-18 21:36:58
I just tested furious using 1.2.2m -q 1.5 -A.
I could ABX the hiss in the 1.8...2.7 second range 10/10, and it wasn't very hard.
For a comparison I retested the same sample snippet using -Z -A -t as I did yesterday. Today I arrived at 9/10, so the hiss is audible too. ABXing was harder though than when using -q 1.5 -A.
Once about to compare I also tested the snippet using -Z -t. I couldn't ABX the hiss I heard using -A.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-18 22:08:47
Thanks again - I'll focus on that region of the sample and compare the output of -Z -t with -Z -A -t.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-20 21:03:13
For anybody wishing to experiment with the current implementation of adaptive noise shaping, there are three hidden parameters for --adaptive:

<filter_length> : 16<=n<=256; default=32;
<warp_lambda> : 0<=n<=0.7; default=1/3;
<persistence> : 0<=n<=1; default=0.1;

Examples:

--adaptive 64 : filter_length=64;
--adaptive x 0.5 : filter_length=default; warp_lambda=0.5;
--adaptive x x 0.2 : filter_length=default; warp_lambda=default; persistence=0.2.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-20 21:59:39
<filter_length> : 16<=n<=256; default=32;
<warp_lambda> : 0<=n<=0.7; default=1/3;
<persistence> : 0<=n<=1; default=0.1;

What exactly each of them affects?
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-20 22:09:12
Filter_length : bigger is better (more accurate), but slower;
Warp_lambda : bigger = more emphasis on accuracy for lower frequencies;
Persistence : 1 = only use spectrogram from this codec-block; 0.5 = use half from previous codec_blocks and half from this codec_block; etc.
Title: lossyWAV 1.3.0 Development Thread
Post by: doccolinni on 2010-06-20 23:30:30
Persistence : 1 = only use spectrogram from this codec-block; 0.5 = use half from previous codec_blocks and half from this codec_block; etc.

Haven't you gotten that backwards? If 1 means use only spectrogram from this codec block, that means the default setting of 0.1 takes into account the current spectrogram with weight 1/10 and the previous spectrogram with weight 9/10.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-21 13:00:12
The present value of the persistence parameter is an attempt to smooth out the desired shape.

lossyWAV beta 1.2.2n attached to post #1 in this thread.

[edit] lossyWAV beta 1.2.2p attached to post #1 in this thread. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-21 21:40:19
I just tried 1.2.2p with furious.

Using -Z --adaptive, 1.2.2p is clearly better than 1.2.2m to me. It's ABXable against the original as was expected, but I wouldn't call the result bad.

Using -Z --adaptive --altpreset I ABXed 1.2.2p 10/10 against the original in the 1.8...2.7 second range.
As usual for a direct comparison I also tried -Z --altpreset, and today I could also ABX it against the original 10/10 in the 1.8...2.7 second range.
Obviously my sensitivity varies (I don't think the non-noise shaping machinery has changed).
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-21 21:43:17
The existing bit-removal and fixed noise-shaped bit-removal processes have not changed at all.

I'm glad that 1.2.2p has given an improvement over 1.2.2m in relation to the hiss encountered in Furious.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-06-29 20:16:35
lossyWAV beta 1.2.2q attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-06-30 19:48:04
I just tried 1.2.2q with furious.
-Z -A isn't hard to ABX (no surprise). It sounds different from the previous version but I wouldn't call it better (or worse).
-Z -A -t wasn't transparent either. As usual I focused on second 1.8...2.7 and ABXed 9/10 against the original.

Sorry: no improvement IMO.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-07-01 16:25:51
Thanks very much for the testing - I'll take it apart and see if I can think of any improvements.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-07-23 17:56:49
To simplify the code, I am thinking of removing the compatibility with libfftw3f-3.dll (single-precision) and reverting to double precision for all calculations. Does anyone have any violent objections to this proposal?
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-07-23 20:02:19
To simplify the code, I am thinking of removing the compatibility with libfftw3f-3.dll (single-precision) and reverting to double precision for all calculations. Does anyone have any violent objections to this proposal?

I personally love things becoming simpler. Can't see a good reason for using single precision as lossyWav is pretty fast with double precision.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-07-26 20:25:24
lossyWAV beta 1.2.2r attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-08-05 09:16:21
I will try it when I'll be back from holiday.
Title: lossyWAV 1.3.0 Development Thread
Post by: Big_Berny on 2010-08-05 09:21:47
There is a known problem within foobar2000 (although more likely to do with cmd.exe itself) when running an executable within the cmd.exe command line from a path which includes spaces. The suggested fix for this is to enclose the element of the path which contains spaces within double quotation marks ("), e.g. c:\"program files"\directory_where_executable_is\executable_name

Isn't it possible to just put the whole path into ""? Like "c:\program files\directory_where_executable_is\executable_name"? IMHO this should be possible and the easiest way as you just can say "<path>".
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-08-05 19:55:17
@halb27 - although you may want to wait until beta 1.2.2s is posted - I have had an idea which I am trying to implement that may improve things.

@Big_Berny - if the executable is on the path then you don't need to specify any path to is, just the executable name.
Title: lossyWAV 1.3.0 Development Thread
Post by: Big_Berny on 2010-08-06 00:44:31
@Big_Berny - if the executable is on the path then you don't need to specify any path to is, just the executable name.

I know. I just wanted to say that you can put the whole path into "" if there are spaces in it. It's easier to make a batch/script then.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-08-07 21:16:32
@halb27 - although you may want to wait until beta 1.2.2s is posted - I have had an idea which I am trying to implement that may improve things.

OK, I wait until 1.2.2.s is out.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-08-08 21:36:34
Thanks for your patience.

lossyWAV beta 1.2.2s attached to post #1 in this thread.

[edit] Suggest -A 96 or greater (default=32) [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-08-10 11:19:59
Thank you, Nick, for the new version.

I tried furious with 1.2.2.s -Z --adaptive 96, and - as was expected - it is rather easy to ABX.
I tried -q 1.0 --adaptive 96, and ABXing was already difficult for me.

But we shouldn't focus so much on furious IMO as I have been doing. While on holiday (walking the wonderful Cotswold Way BTW) I was thinking about what can be expected from adaptive noise shaping. The big picture with adaptive noise shaping was adressed in this thread, but without a final result. IMO it is important to discuss this.

Before adaptive noise shaping came up we have always targeted at universal transparancy as this is what is best in line with the lossyWAV principle. We even did so with the portable quality level though we allowed it to be on the very cutting edge.

With adaptive noise shaping I now think we shouldn't do that because I think there will be always artificial samples where adaptive noise shaping can't help which brings us to average bitrates we're used to without noise-shaping. For those who use lossyWAV preprocessing as an efficient alternative to pure lossless encoding adaptive noise shaping isn't interesting a priori. Adaptive noise shaping is most interesting for those who want to use lossyWAV preprocessed lossless as an alternative to very high bitrate mp3 or aac (or similar). In order to have this usage of lossyWAV attractive it should compare favorably in some respect. I suggest the following targets:

- no problems with temporal resolution (as opposed to pre-echo problems) in a universal way
- no other kind of artefacts in a universal way
or in other words:
- only a tiny amount of audible added hiss is allowed on problem samples, and added hiss should be inaudible with natural music.

This should be achieved at an attractive average bitrate, say roughly 300 kbps or below.

furious is an artificial sample, so we shouldn't care much about a small amount of added hiss.
The quality level -Z --adaptive however also shows up certain amounts of what we've called added clicks which can be classified as artefacts. Maybe it's possible to improve upon that. With -q 1.0 these artefacts are next to nothing.

What is most important is listening tests with non-artificial music on a broad scale. I will try that. It would be nice however if some more members could contribute to get a broader experience basis.
Title: lossyWAV 1.3.0 Development Thread
Post by: shadowking on 2010-08-10 12:15:37
I finally did a little test very casual without headphones.

Serioustrouble - very big improvement - cannot abx Q0 -A but -Q is very easy.
Dear Sir -  Maybe a little bit better but still easy to abx.
Mandylion - 5/10 Q0 -A vs 8/10 Q0
Sarah Mac - ice - Both are the same.


In general -A can be a good thing, but i need a much more through test with headphones.



Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2010-08-10 17:42:44
First of all: thanks to everyone doing listening test.
For those who use lossyWAV preprocessing as an efficient alternative to pure lossless encoding, adaptive noise shaping isn't interesting a priori. Adaptive noise shaping is most interesting for those who want to use lossyWAV preprocessed lossless as an alternative to very high bitrate [lossy].

This will depend on what ANS will bring us, if it would happen that the same level of transparency (or headroom thereof) can be achieved with maybe 50kps less when using ANS, that would be appealing to the "efficient alternative to lossless" users too.

Adaptive Noise Shaping only makes sense if it brings an improvement in either lower bitrates at the same quality or higher quality at the same bitrates. These issues are most relevant around the "just transparent" border that could be --portable.

Nick is bringing an interesting experiment to see if Adaptive Noise Shaping can be turned into our advantage.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-08-10 19:53:04
@shadowking:
Does 'Dear Sir' originate from natural instruments or is it artificial music? Is the error added hiss or kind of an artefact?
Is 'Sarah Mac - ice' transparent or not, and if not: is it non-artificial music, and is the error hiss or artefact?
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-08-10 21:14:05
Bitrate results for my 55 problem sample set:
Code: [Select]
+-------+----------+----------+----------+----------+----------+----------+
|Version| Settings | FLAC -5  |--insane  |--extreme |--standard|--portable|
+-------+----------+----------+----------+----------+----------+----------+
|       | default  | 654kbit/s| 584kbit/s| 510kbit/s| 427kbit/s| 325kbit/s|
| beta  +----------+----------+----------+----------+----------+----------+
|       |--shaping | 658kbit/s| 589kbit/s| 515kbit/s| 431kbit/s| 325kbit/s|
|1.2.2s +----------+----------+----------+----------+----------+----------+
|       |--adaptive| 654kbit/s| 584kbit/s| 509kbit/s| 426kbit/s| 323kbit/s|
+-------+----------+----------+----------+----------+----------+----------+
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-09-15 11:05:51
Sorry it took me so long, but finally I've managed to finish my listening test of 120 tracks of regular music from my collection of various genres (pop, classic, singer/songwriter music, instrumental music), and of 13 problem samples.
With adaptive noise shaping lossyWAV is so good with even low bitrate that it wasn't much fun and I allowed for a lot of breaks.

First I decided about the setting to use. For quality below standard it makes most sense to me to use the altpreset quality scheme (more efficient due to the slightly lower analysis limit, but more defensive otherwise). In case we assume adaptive noise shaping is useful we should also use it for quality below standard IMO. These considerations may or may not apply for standard and above (and are a matter of taste anyway) - I ignore this for the moment.

With our quality steps of 2.5 this means quality levels below standard as of:

--portable (-q 2.5 --altpreset --adaptive 96):                                             373 kbps (on average for my test set of regular music)
--superportable [my suggestion] (-q 0 --altpreset --adaptive 96):    321 kbps
--maxportable [my suggestion] (-q -2.5 --altpreset --adaptive 96):  280 kbps

For my test I used -q -2.5 --altpreset --adaptive 96.

In short I was very pleased with the quality of this setting. I often thought I heard a problem, but when ABXing I nearly always found that the 'problem' was with the original as well.

In the end I found just the following cases of intransparency among the real world tracks:

Sweet Old World (http://dl.dropbox.com/u/2681777/problems/Sweet%20Old%20World%20-%20Emmylou%20Harris%20%5BWrecking%20Ball%5D.flac): The sibilants are rougher here, but it's not obvious at all (8/10).
Ta douleur (http://dl.dropbox.com/u/2681777/problems/Ta%20douleur%20-%20Camille%20%5BLe%20fil%5D.flac): The french 'r' is rougher. I'm sure it's not transparent though I got only at 7/10 (repeatedly).
Köln Concert (http://dl.dropbox.com/u/2681777/problems/Part%20I%20-%20Keith%20Jarrett%20%5BThe%20K%C3%B6ln%20Concert%5D.flac): Temporal smearing when listening with my electrostatic headphone (8/10), but I couldn't hear the problem with my Alessandro MS2 (modified Grado 325). I should mention I'm not sensitive to temporal smearing, so this may be more of a problem to those who are.
Tout le monde (http://dl.dropbox.com/u/2681777/problems/Tout%20le%20monde%20-%20Carla%20Bruni%20%5BQuelqu%27un%20m%27a%20dit%5D.flac): I'm not quite sure for this sample. It sounded rougher to me on my electrostatics (but only 7/10), but I couldn't here the issue with my MS2.

As for the problem samples I first listened to furious again. Now I think intransparency is only due to hiss, not kind of an artefact as I thought before. The hiss just sounds like a bit of 'wobbling' because there is kind of a modulation in the signal.
I also found the following problem samples not transparent:
herding calls (http://dl.dropbox.com/u/2681777/problems/herding_calls.flac): inprecision (quite similar to mp3 behavior), not very obvious though in spite of my 9/10.
eig (http://dl.dropbox.com/u/2681777/problems/eig_essence.flac): slight temporal smearing when listening with my electrostatics (only 7/10), not confirmed when using my MS2. Keep in mind I'm not good at ABXing temporal smearing.

So all in all extremely rare spots of minor intransparency to me.

As the next step I'll try different --adaptive parameters for the identified problems to see if this will improve things. I'm also interested to see how q 0 --altpreset --adaptive 96 will perform on the problematic spots.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-09-15 19:17:49
Wow! That's quite a test program to have undertaken. I am amazed that --maxportable (-q -2.5 --altpreset --adaptive 96) has proven to be so robust in practice.
Title: lossyWAV 1.3.0 Development Thread
Post by: C.R.Helmrich on 2010-09-19 20:20:21
Hi Nick, all,

I gave the latest 1.2.2 a try today and noticed that on many files, for -I down to -P, more noise tends to be added (i.e. LSBs removed) on the right channel than on the left channel, even if the input file has the same energy/spectral shape in both channels. Try it with SQAM track 2 (http://tech.ebu.ch/publications/sqamcd), for example. There I get about 2 dB more noise (SNR reduction) on the right channel with -P, no noise shaping.

Chris
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-09-19 20:48:46
Chris,

Many thanks for taking the time to try lossyWAV - and also for highlighting what appears to be a (significant) bug.

Nick.

[edit] Were you testing main quality scale or altpreset and did you use any noise-shaping? [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: C.R.Helmrich on 2010-09-19 21:00:01
[edit] Were you testing main quality scale or altpreset and did you use any noise-shaping? [/edit]

I used a minimal command line: lossyWAV.exe input.wav -P. No noise shaping.

If I may ask: How does LossyWAV in non-noise-shaping mode determine when to chop off LSBs? Simply based on the amplitude or energy of the current frame, or something more complicated?

Chris
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-09-19 21:21:54
If I may ask: How does LossyWAV in non-noise-shaping mode determine when to chop off LSBs? Simply based on the amplitude or energy of the current frame, or something more complicated?
Each codec block has a number of overlapping FFT analyses carried out on it at two or more lengths (approx 1.5 msec equivalent and 10 msec equivalent and others in between).

The results from each are "skewed" using a curve that reduces the FFT bin results by 36dB at the lowest bin and 0dB at approx 3.4kHz.

In the frequency range of interest (default 20Hz to 16kHz), the lowest result is then found, along with the average (using a pair of simple spreading systems). These are modified by parameters dictated by the selected quality setting.

For each FFT length there is a lookup table to translate the chosen lowest result each FFT analysis of that length to a number of bits-to-remove.

The lowest allowable bits-to-remove value is chosen between all analyses at all FFT lengths for each channel.

If channels are not linked then the number of bits removed from the audio data is independent per channel.

There is a clip detection mechanism in place to stop more than <n> clips occuring per codec-block-channel. When the limit is exceeded then the number of bits-to-remove is reduced by one and the bit-removal process is repeated. Some codec-block-channels will not have any bits removed due to clipping.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-09-22 22:13:54
After some bug-hunting (with a bit of brain-failure mixed in), I have concluded that any difference in added noise per channel Chris encountered processing stereo signals with similar energy / spectral shape in each channel can be put down to the clipping prevention kicking in and reducing the bits-to-remove for enough codec-blocks to make an observable difference.

[edit] Clarity [/edit]

Chris,

I would suggest that you repeat your test with "--maxclips 16" in your command line.

Nick.
Title: lossyWAV 1.3.0 Development Thread
Post by: shadowking on 2010-09-23 11:39:45
On another note:

Lossy WV is considered not efficient compared to flac. I am pleased to find that its more competitive (in some cases a lot) when using the -x switch. The sweetspot between size / speed seems to be the normal mode using -x levels 1-3.  The fast mode also benefits a lot. For some reason the high modes don't bring any gain except making encoding / decoding slower.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-09-24 22:04:13
Tonight, I completed a transcode of my music collection using beta v1.2.2s "-q -2 -A 96 -t" which resulted in 302kbps.
Title: lossyWAV 1.3.0 Development Thread
Post by: C.R.Helmrich on 2010-09-24 22:29:41
Thanks, Nick, for the long explanation! So it is "slightly" more complicated than I thought

I would suggest that you repeat your test with "--maxclips 16" in your command line.


Did that, the result is bit-identical to not using the switch. The test item, SQAM #2, is far from clipping, anyway (peak level -34 dB).

Chris
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-09-25 10:14:39
Right then, time to don the pest control gear and go bug-hunting again....
Title: lossyWAV 1.3.0 Development Thread
Post by: C.R.Helmrich on 2010-09-25 10:31:28
Took a look at SQAM 2 again, the channels actually have slightly different levels of DC offset/LF rumble. Could that be the reason? Which window function are you using in your FFTs?

Chris
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-09-25 10:37:53
The Hanning window is used.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-09-25 10:47:42
Though the actual discussion might show up a problem with lossyWav, at least there is no obvious different treatment of the left and right channel for SQAM sample #2 within lossyWAV:
The error (the correction) file is bit-identical for 02.flac and the channel-swapped error-file of the channel-swapped 02.flac. I used sox for channel-swapping.
Title: lossyWAV 1.3.0 Development Thread
Post by: C.R.Helmrich on 2010-09-25 11:05:37
Interesting. Thanks, halb27! So it must be related to either the LF or HF differences in the signal. Nick, what happens when you let the masking analysis start at, say, 40 Hz instead of 20 Hz?

Edit: That should fix it. I manually removed the (minimal) DC offset from the right channel, and now it looks better. 20 Hz is probably too close to DC when you use a Hann window.

Chris
Title: lossyWAV 1.3.0 Development Thread
Post by: bryant on 2010-09-27 01:18:24
Lossy WV is considered not efficient compared to flac. I am pleased to find that its more competitive (in some cases a lot) when using the -x switch. The sweetspot between size / speed seems to be the normal mode using -x levels 1-3.  The fast mode also benefits a lot. For some reason the high modes don't bring any gain except making encoding / decoding slower.

I agree that removing the -h from the example command-line and replacing it with a -x (or even -x3) would be a better trade-off for WavPack. Thanks for pointing this out!

BTW, the reason that the higher modes do not provide additional compression is because the block headers are significantly larger for the higher modes. With only 1 or 2 blocks per second this is insignificant, but with the extremely short blocks associated with LossyWAV these larger headers are no longer offset by the better compression of the data itself.
Title: lossyWAV 1.3.0 Development Thread
Post by: Enig123 on 2010-09-30 03:29:30
In the lossyWAV wiki, there's a paragraph mentioned that lossyWAV may work with MLP via "Bit-Shifting". Has anybody ever tested it?

As I know, MLP (Dolby TrueHD) is designed for multi-channel lossless compression, which indicate that it might not work well with 2-ch music from CDs. I'm very curious to know if lossyWAV can work well with multi-channel audio streams together with FLAC and MLP.

Can anybody in this forum has the opportunity to do the corresponding tests?
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-10-09 13:47:15
Looking to the next release:

Is anyone using -X, --sortspread? If not, I will remove it as it complicates the code and slows things down a little.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-10-14 02:23:10
If nobody uses it I welcome removing it.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-10-14 19:32:07
Sounds good to me - it's history....
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-11-11 21:02:29
lossyWAV beta 1.2.2t attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: TBeck on 2010-11-12 01:45:41
Hi Nick,

i am working on a dedicated LossyWav codec for the next TAK release (quite a lot of work illustrating my appreciation for your and 2Bdecided's work  ). If it will be released depends on the advantage over TAK's standard codec i can achieve. Currently i am getting about 1.5 percent better compression and i am aiming for 2 percent (relative to the original file size). IMHO this would be worth a release.

Among other things this codec can process small frames more efficiently. This raises the question, how small LossyWav's block sizes can get, if a codec can process them without a significant penalty. Currently the new codec supports a minimum block size of 256 samples. Do you think, even less could be advantegous?
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-11-12 06:23:14
A 2% reduction over TAK sounds like quite a challenge! Thank you for taking the time to implement lossyWAV specific algorithms in TAK.

Although smaller blocks may reduce specific output size (due to more bits being removed on average), the size of any block header should be taken into account. At present the codec-block-size for lossyWAV is 512 samples for 44.1/48kHz audio with a maximum of 4096 samples for 352.8/384kHz. I worry that you may get into a situation where the smaller block size is less efficient due to block related information rather than the compressed audio itself.
Title: lossyWAV 1.3.0 Development Thread
Post by: TBeck on 2010-11-12 13:55:04
Although smaller blocks may reduce specific output size (due to more bits being removed on average), the size of any block header should be taken into account. At present the codec-block-size for lossyWAV is 512 samples for 44.1/48kHz audio with a maximum of 4096 samples for 352.8/384kHz. I worry that you may get into a situation where the smaller block size is less efficient due to block related information rather than the compressed audio itself.

Of course, but the new codec can cope a lot better with small block sizes. If it requires only the modification of a constant, could you please send me a V1.2.0 with a block size of 256 samples for 44.1 KHz audio?
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-11-12 19:06:18
I'll have a look and get something to you, hopefully this evening.

[edit] eig file attached, codec-block-size=256 samples. [/edit]

[edit2] file removed - not required. [/edit2]
Title: lossyWAV 1.3.0 Development Thread
Post by: TBeck on 2010-11-14 21:50:01
[edit] eig file attached, codec-block-size=256 samples. [/edit]

Thank you Nick. And sorry. I wasn't clear enough.

What i really need is a modified version of LossyWav V1.2.0 working with a block size of 256. I have to perform a lot of tests on my test corpus to be sure, if such a small blocksize is advantegous for the new codec.

It's not urgent.

Thank you

  Thomas

BTW: About 2 percent better compression is definitely possible, even with the default block size of 512. Currently i am close to 1.8 percent for my primary test corpus.

Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-11-14 22:49:56
I'll work on something not quite so agricultural as the version I created the test version of eig with. Please PM me your e-mail address so that I can e-mail you the test executable.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-12-02 20:46:19
lossyWAV beta 1.2.2w attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-12-02 21:43:01
Thank you, Nick, for the new version.

Though I decided to use mp3 (because of family/friend related compatibility issues) I'm still very excited about lossyWAV development.
I didn't have much time recently for lossyWAV (I was in hospital, and after that was busy with other things), but I hope I can do some more listening tests in the near future, especially as the new version is a good reason to do so.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-12-06 21:13:26
Again, many thanks for all of the testing that you have carried out over the period of development so far!
Title: lossyWAV 1.3.0 Development Thread
Post by: jetpower on 2010-12-06 23:51:13
Hi,
I don't understand much of what LossyWav does, however one thing bothers me.  What is the purpose of --limit? Does it mean LossyWav ignores everything above 16kHz?
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-12-07 07:45:21
The audio above the upper limit used to determine the low points in the frequency spectrum is still processed but does not influence the calculation of bits-to-remove from each coded block.
Title: lossyWAV 1.3.0 Development Thread
Post by: jetpower on 2010-12-07 16:07:13
Is --limit then meant as a kind of psy trick since we don't hear HF very well?
I remember there was a parameter which made LossyWav remove bits more from HF. It was then dropped (I can't find the name of it). Is there something similar in recent versions? Also would LossyWav benefit from checking bits-to-remove against ATH curve? Thanks
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2010-12-07 17:45:32
--limit isn't a psy trick, it's just the frequency limit for the energy analysis (searching the frequency area with lowest energy - the lowest energy found is used to determine the number of bits to remove).
There must be such an analysis limit because in the extreme HF area chance is very high to find a frequency area with very low energy making bits to remove zero or close to zero for no good reason.

--limit is 16 kHz by default when not using -t, when using -t it's a tiny bit lower (roughly 15.3 kHz).

--limit has nothing to do with frequency range, --limit is kind of a short name for --analysislimit.
Title: lossyWAV 1.3.0 Development Thread
Post by: jetpower on 2010-12-07 18:58:56
--limit isn't a psy trick, it's just the frequency limit for the energy analysis (searching the frequency area with lowest energy - the lowest energy found is used to determine the number of bits to remove).
There must be such an analysis limit because in the extreme HF area chance is very high to find a frequency area with very low energy making bits to remove zero or close to zero for no good reason.


So --limit exist because ultimately in the extreme HF area, like 20kHz, music is very faint or non-existent and LossyWav has to go for the lowest common denominator in frequency spectrum (i.e. local noise floor). Is this correct?

The audio above the upper limit ... does not influence the calculation of bits-to-remove from each coded block.

so for frequencies above --limit, which are HF and less audible, LossyWav can 'zero' too many bits from a high energy HF part, because it has no way of knowing about it?
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-12-07 19:10:43
1) Yes, limit exists because there is no point in limiting the bits-to-remove by taking into account audio that you cannot* hear;

2) Yes, because the calculation disregards the portion of the frequency spectrum between the (upper-calculation-)limit frequency and Nyquist, more loss will probably occur in the high frequencies than if they had been taken into account during the calculation of the lowest energy portion of the spectrum.

* Unless you have exceptional hearing, are young or are a bat / dog / etc.
Title: lossyWAV 1.3.0 Development Thread
Post by: jetpower on 2010-12-07 19:47:23
Thanks Nick.
Quote
2) Yes, because the calculation disregards the portion of the frequency spectrum between the (upper-calculation-)limit frequency and Nyquist, more loss will probably occur in the high frequencies than if they had been taken into account during the calculation of the lowest energy portion of the spectrum.

So in effect --limit it is a kind of psy trick too. You agree? Would it not be better by design then if LossyWav checked audibility of noise floor against ATH? If current noise floor is below what we can hear anyway then Lossywav can be more aggressive/efficient. Maybe then --limit would not be needed because many HF parts would be disregarded by this. Sorry if this sounds dumb.
Also when LossyWav 'zeroes' bits can it also 'one' bits in block?  Lossywav could check which (zero-ing or one-ing) better fits for this block and achieve better compression, or alternatively, modify less bits. Again, sorry if this is nonsense.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-12-07 20:16:32
If by psy trick you mean "ignore what you (probably) can't hear" then yes.

There is no real psy-model as such in lossyWAV.

The bit removal process at its simplest rounds off LSBs. Next, there is fixed noise shaping (optimised for 44.1kHz and 48kHz using SebastianG's filter coefficients) - this uses the round off values and noise-shapes the output. Finally there is adaptive noise shaping (in beta) which uses SebastianG's frequency warped method to "hide" the added noise behind the signal itself, again using the round off values as primary input.

I don't know if making the LSBs all ones would work - I'll try it and see what happens.
Title: lossyWAV 1.3.0 Development Thread
Post by: jetpower on 2010-12-07 20:43:08
If by psy trick you mean "ignore what you (probably) can't hear" then yes.

yes , exactly

Quote
There is no real psy-model as such in lossyWAV.

I know but i don't like --limit in place of it.

Quote
The bit removal process at its simplest rounds off LSBs. Next, there is fixed noise shaping (optimised for 44.1kHz and 48kHz using SebastianG's filter coefficients) - this uses the round off values and noise-shapes the output. Finally there is adaptive noise shaping (in beta) which uses SebastianG's frequency warped method to "hide" the added noise behind the signal itself, again using the round off values as primary input.

I'd need to read up on what noise shaping does and why is it important. Now I don't get the point of it.

Quote
I don't know if making the LSBs all ones would work - I'll try it and see what happens.

Great! Happy I was able to contribute an idea. Theoretically in (nearly) 50% of cases one-ing LSBs would be better. AFAIK, FLAC and others code each block separately so 0/1 decision should be on block-basis then.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-12-07 20:56:33
If you don't like --limit then use --limit 20000.

I will not remove it - I have no interest in ultrasonic content.
Title: lossyWAV 1.3.0 Development Thread
Post by: jetpower on 2010-12-07 21:04:21
If you don't like --limit then use --limit 20000.

I will not remove it - I have no interest in ultrasonic content.

No, sorry I did not intend to sound negative. I am totally amazed by your persistent work on improving Lossywav. I would welcome a replacement for --limit, that is all. Unless there is one, it has to do. Lossywav has to cut corners somewhere and it's better if it does in it HF. That is why I asked in a previous post about this parameter that shifted noise to HF.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2010-12-07 21:14:09
There may be some confusion - at one time I misnamed a pair of parameters as --lowpass / --highpass when they should have been named --lowlimit and --highlimit or something like that, as they were parameters to set the lower and upper frequency limits of the calculation to find the lowest energy portion of the spectrum.

It occurs to me that the fixed noise shaping method used in lossyWAV shifts the added noise into the high frequency portion of the output - maybe that is what you are remembering.
Title: lossyWAV 1.3.0 Development Thread
Post by: jetpower on 2010-12-07 21:23:51
It occurs to me that the fixed noise shaping method used in lossyWAV shifts the added noise into the high frequency portion of the output - maybe that is what you are remembering.

Probably that's the one:) Thanks for all the help with explaining.
Title: lossyWAV 1.3.0 Development Thread
Post by: pdq on 2010-12-07 22:53:50
I don't know if making the LSBs all ones would work - I'll try it and see what happens.

Since that is only one LSB different from making them all zero, I don't see the point.

If, OTOH, you could make them all the same value within a block, and select the value that minimized the added noise, then that would be worthwhile.
Title: lossyWAV 1.3.0 Development Thread
Post by: jetpower on 2010-12-08 13:32:18
If, OTOH, you could make them all the same value within a block, and select the value that minimized the added noise, then that would be worthwhile.

That was the idea. If the situation is like this:

1 0 1 1
0 1 0 1
1 1 0 0
1 0 1 1
0 1 1 0
1 1 1 1
1 1 0 1
0 1 0 1

Then '0's marked in red would be better replaced by '1's
Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2010-12-08 20:30:06
Would it not be better by design then if LossyWav checked audibility of noise floor against ATH?
It's a possible development, and it sounds like it should help, but might not in reality...

Firstly, decent lossy codecs have a floating ATH that adapts to the loudness of the signal. Lame didn't use to, but has done for a while. Without it, encoding a quiet track and then turning it up reveals coding artefacts. So, if you use ATH data, you have to tie it in some way to the incoming audio signal. That's another thing to tune.

Secondly, lossyWAV doesn't usually have audible artefacts at very high frequencies, even when you force it to add more noise. If you make it go wrong, the audible problems are usually at mid-frequencies. Sometimes an ATH model will add less noise than the simple hard limit, sometimes more. If what's there already is transparent, then adding less noise is pointless. If what's there already is transparent, then adding more noise is risky.

So, it could be done - and if ever lossyWAV had a psychoacoustic model it probably should be done. But a simple cut-off serves quite well.

You can't have no cut off - if you analyse everything out to 22.05kHz, you'll find lots of CDs have a very low noise floor above 20kHz, and lossyWAV wouldn't touch these at all.

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2010-12-08 20:34:09
If, OTOH, you could make them all the same value within a block, and select the value that minimized the added noise, then that would be worthwhile.
Over 512 samples it's hard to see it could make a noticeable difference except in exceptional circumstances.

The LSBs that are thrown away are essentially random. Simplistically, if they weren't, they wouldn't be being thrown away.

(That is simplistic - it's easy to create or manipulate a signal so that they're not random at all but will all be thrown away - but not so easy to record such a signal with a microphone!).

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: punkrockdude on 2011-01-01 08:06:03
I am so impressed by how -q -2 -t -A 96 sounds and even when I change it to -q 0. What does the -t and -A 96 switches do? If I have 24 bit files that I would like to use, should I change any parameter? Regards
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-01 10:55:57
Glad you're enjoying it. Using -q 0 instead of -q -2 in that set of parameters will increase quality a bit. No additional commands are required for 24bit.

[edit] -A 96 enables adaptive noise shaping using a 96 tap FIR filter; -t enables alternative internal presets. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: SebastianG on 2011-01-01 13:29:15
[edit]-A 96 enables adaptive noise shaping using a 96 tap FIR filter;[/edit]

Oh ok, so the original LossyWav already implements ANS. Well, I hope you don't mind that I experimented a little on my own w.r.t. ANS.

Cheers and a happy and productive new year!
SG
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-01 17:09:21
No problems Sebastian - I am intrigued by your "simple psychoacoustic model" though....
Title: lossyWAV 1.3.0 Development Thread
Post by: SebastianG on 2011-01-02 13:00:16
No problems Sebastian - I am intrigued by your "simple psychoacoustic model" though....

I simply compute the average power spectral density of the signal for each of 64 non-uniformly placed subbands with bandwidths ranging from 100 Hz (lower bands) to 1 kHz (higher bands). The levels are in dB relative to the level of noise from a rectangular dither (+/- 1/2 LSB). From these 64 levels I compute tolerable noise levels by subtracting a frequency-dependent signal-to-noise ratio. (Currently 42 dB for frequencies below 500 Hz and 12 dB for frequencies above 4 kHz). These SNRs can be adjusted via the commandline parameter. However, they are restricted to be no smaller than 6 dB so the noise is always at least 6 dB lower than the signal. The noise levels are also restricted to be no lower than -10 dB. To avoid high jumps in noise levels from one subband to another, some noise levels are decreased so that the difference between neighbouring bands is at most 5 dB. Finally, I use quadratic B-Splines to "interpolate" the noise levels to a smooth curve. From this curve, the noise shaping filter parameters as well as the bits2remove value is determined.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-05 22:05:27
lossyWAV beta 1.2.2x attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: tycho on 2011-01-06 12:13:44
Thanks Nick for your great efforts.
Somewhat OT and nothing fancy, but I made a lossyFLAC script that also integrates well with dBpoweramp:
Code: [Select]
@echo off
REM Encode WAV to FLAC via lossyWAV - by tycho 2011

set dir=%~dp0
if "%~1"=="" (
  echo Usage: %~nx0 lossywav_args @ flac_args
  echo.
  echo    ex: %~nx0 track01.wav --standard @ -5 -o track01.lossy.flac
  goto :eof
)
set lw_args=
set fl_args=
:lw_loop
  shift
  if "%~0"=="" goto run
  if "%~0"=="@" goto fl_loop
  set lw_args=%lw_args% %0
goto lw_loop
:fl_loop
  shift
  if "%~0"=="" goto run
  set fl_args=%fl_args% %0
goto fl_loop

:run
"%dir%lossyWAV.exe" %lw_args% --silent --stdout | "%dir%flac.exe" - -b 512 -f %fl_args%
Simple standalone usage: lossyFLAC.cmd  file.wav @ -o file.lossy.flac
Note that lossyWAV arguments should be placed before the @, and flac args after. Also, lossyWAV.exe and flac.exe must be present in the same folder as lossyFLAC.cmd.

If you know how to configure command line encoders using the dBpoweramp CLI plugin, it should be easy to integrate this. Basically, the encoder location is set to "encoder\LossyFLAC\lossyFLAC.cmd", and arguments to e.g. "- --standard @ -5 -o [outfile]". encoder.txt should contain: .lossy.flac (I prefer .[L].flac).
[edit: minors, script untouched]
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-08 21:26:34
lossyWAV beta 1.2.2y attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-10 20:22:57
lossyWAV beta 1.2.2z attached to post #1 in this thread. This is release candidate #1 for lossyWAV 1.3.0.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-01-13 10:07:08
I did a listening test with 1.2.2.z using -q -2.5 --altpreset --adaptive 96 as I did with my last listening test last year. This setting produces an average bitrate of 283 kbps on my test set of various popular music.

I tested those samples that didn't come out totally fine with my last listening test.
For regular music this was 'Köln Concert', 'Sweet Old World', 'Ta douleur', 'Tout le monde'.
I tried really hard, but couldn't ABX any difference to the original (nor do I have any suspicion that's something's not right).
As for the problem samples the situation isn't quite as perfect (as was expected). 'herding calls' was fine to me, furious was - as always - the clearest thing to be ABXed due to the hiss which makes furious sound 'brighter'. This time however I could only spot the problem at sec. 0 ... 0.8. eig is certainly ABXable though I only got at 7/10. Quite interesting that lossyWAV can have problems with temporal resolution too.

Anyway the issues with furious and eig are hardly perceptible and not annoying to me. Moreover these samples can't be exactly called music (as is the case with many problem samples). So I think lossyWav 1.2.2.z -q -2.5 --altpreset --adaptive 96 is an excellent setting for portable listening.

I also tried lossyWav 1.2.2.z -q 0 --altpreset --adaptive 96 on furious and eig and couldn't ABX deviations from the original. This setting yields an average bitrate of 323 kbps on my standard test set.

I also wanted to try the subparameters <warp_lambda> and <persistance> of the adaptive option but it looks as if they are not available any more. Not too bad though because with earlier experiments I didn't get very encouraging results. I did encounter ABXable differences but for some samples <warp_lambda>=0 and <persistance>=0.5 was best among the parameters I tested, while on other samples <warp_lambda>=0.6 and <persistance>=0 was best.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-01-14 11:55:40
Today I gave lossyWavANS a try and tested it with furious on my pc with alessandro MS-2 headphones. For comparison I also tested furious again using lossyWav 1.2.2.z -q 0 --altpreset --adaptive 96. Today I got at 7/7 and finished 8/10. The difference is subtle to me though. Yesterday I tested with my notebook attached to an electrostic headphone which usually is the more sensitive device. Not true for furious obviously (or maybe I am more sensitive today having tested furious several times now within two days).
Title: lossyWAV 1.3.0 Development Thread
Post by: Ljubo44 on 2011-01-16 22:18:53
Hi! How can I get lossyWAV to work with WMA Lossless. What is the command line for foobar2000
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-17 06:16:45
See post #1. Sorry - typing faster than the speed of thought never gets the right answer - there was a conversion somewhere, I'll try to dredge it up....

You could try to convert initially to lossy FLAC or Tak or Wavpack and then transcode (losslessly of course) to WMALSL using information from this thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=47759). You will also have to check that you have the relevant WM encoder pack installed as well.
Title: lossyWAV 1.3.0 Development Thread
Post by: punkrockdude on 2011-01-17 20:20:57
I just want to say that I am impressed by LossyWAV. I am trying out "-q -2 -t -A 128" and for the size (around 300 kbps) it sounds so good. Full frequency range and so far I hear NO noise. I will do an ABX some time. Keep it up!
Title: lossyWAV 1.3.0 Development Thread
Post by: punkrockdude on 2011-01-17 21:00:03
Nick.C:
Your "-q -2 -t -A 128" sounds really, really good even when I use my Beyerdynamic DT880 Pro. What command line would you use to make the files even smaller where I can accept a little noise to put on my HTC to play outside in noisy environments? I tried to change from -2 to -0 but the bitrate increased. Any suggestion? Regards
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-17 21:04:20
You could try something in the range -q -4 to -q -2. Using -t (--altpreset) changes the lower quality limit to -4 (although this is the same as -q 0 in the default scale with the exception of the upper frequency limit used for analysis purposes) and also changes the upper frequency limit for analysis purposes to 15159Hz.

[edit] You could also lower the upper frequency limit used for calculation purposes by using the --limit (-l) parameter with a selected frequency in the range 10000 to 20000Hz. The default is 16000Hz and 15159Hz is used for the --altpreset scale. This is, however, likely to add more noise. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-01-18 09:13:22
As for Nick's suggestion I can add that -q -4 -t still is very very good from my experience with a former version of lossyWAV (and lossyWAV seems to have improved since then).
I once experimented with lower values of --limit and found --limit 14500 (resp. --limit 14470 as Nick's optimizied suggestion) still to be very good.
So I think you'll be totally content with -t -q -4 --limit 14470 or similar especially if you are willing to allow for a tiny bit of noise on rare occasion. If you should consider to allow even for a higher amount of very high frequency noise (not necessarily audible) you can consider to go even lower with --limit. Things become significantly critical only if you go lower than --limit 13500.
It's questionable however whether it's worth while. You won't get a significantly lower bitrate than when using say -q -2.5 -t which is more solid. A matter of taste.
Title: lossyWAV 1.3.0 Development Thread
Post by: googlebot on 2011-01-18 10:46:18
Modern audio codecs have come so far and become so good, that I have stopped looking for a better overall quality/bitrate ratio than AAC. I also see people being amazed, how good lossyWAV has become at portable bitrates. I don't doubt this and respect the achievement. But what's the purpose of lowering lossyWAV's point of general transparency even further? AAC, for example, is already there, has a much more advanced toolbox at its disposal, and is nearly perfect at ~200 kbit/s VBR, with very few exceptions. Between AAC and lossless I rather miss a codec for which no ABXable samples are known in the 300-400 kbit/s range.

Wouldn't achieving 0.000% risk of artifacts be a much nicer goal than further lowering the point of general transparency? The new ANS and psy-models seems to be working nicely at achieving the latter, but I'm afraid the added complexity might increase the absolute risk of failure for extreme samples.

Have I just missed, that there already is a preset with no known problem samples? If not, is any improvement planned in that area or are ANS and psy-model tuning going to get the most attention in the near future?
Title: lossyWAV 1.3.0 Development Thread
Post by: carpman on 2011-01-18 13:18:42
My understanding, and I may be wrong, but nothing > -2.5 (i.e. portable has been ABX'd). I'd like to know the answer to this also. Certainly --standard (-q 5) so far is 100% transparent.

C.

ps. I kind of agree with you googlebot, I'm not entirely sure of the purpose of lossyWAV going into the non-transparent territory < 300 kbps when transform codecs do such a good job there. But then it's interesting to see how far it can be pushed, I guess.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-01-18 15:10:20
I also see the main purpose with lossyWAV to get transparent results with a probability which is extremely close to 1. Nick managed to achieve this more or less from the very start - at a bitrate of roughly 500 kbps on average. A nice bitrate reduction already compared to plain lossless. With his restless efforts we can achieve the same quality level now at a bitrate which is not far beyond 300 kbps using for instance -q 0 -t -A (or a bit more defensive setting for the cautious one).

BTW: I just saw I forgot the -A parameter in my last post (#233). I can't edit it any more.
Title: lossyWAV 1.3.0 Development Thread
Post by: misuzu on 2011-01-18 20:03:34
I think if use -t and quality is equal or greater than -q 5

it can consider to use --limit 16000 replace --limit 15159 in default

because for most of people , 16k is safe in mental efforts in MP3 and doesn't increase too much bits

if -t is stable , it can replace old -q setting in default

sorry , my English is poor
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-18 21:35:14
....,  but nothing > -2.5 (i.e. portable has been ABX'd).
Nothing greater than -q 2.5, I believe.

I'm not entirely sure of the purpose of lossyWAV going into the non-transparent territory < 300 kbps when transform codecs do such a good job there. But then it's interesting to see how far it can be pushed, I guess.
To me, the further down the quality scale that the apparent transparency point exists, the better - no?

With his restless efforts we can achieve the same quality level now at a bitrate which is not far beyond 300 kbps using for instance -q 0 -t -A (or a bit more defensive setting for the cautious one).
Totally sprung - I just can't stop tweaking the code.... 

I think if use -t and quality is equal or greater than -q 5

it can consider to use --limit 16000 replace --limit 15159 in default

because for most of people , 16k is safe in mental efforts in MP3 and doesn't increase too much bits

if -t is stable , it can replace old -q setting in default
I would rather leave the --altpreset system alone - you can always modify the default upper frequency limit for calculations in --altpreset by adding "-l 16000" on the command line. It should be restated that the frequency defined by --limit is for the calculation which finds the lowest part of the signal. It does not affect where the added noise due to rounding goes - that is defined by whether (or not) the user selects shaping (fixed shaped noise), adaptive shaping (behind the signal, sort of....) or does not select shaping at all (full spectrum noise).

[edit] I forgot to add - there are users who have expressed unhappiness previously when the resultant bitrate at the lowest quality settings increased during development - my desire to drive the apparent transparency point down the quality scale is mainly prompted by the wishes of these users. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: googlebot on 2011-01-18 22:37:22
....,  but nothing > -2.5 (i.e. portable has been ABX'd).
Nothing greater than -q 2.5, I believe.


If nothing indeed means zero, that's all I need to know. Thanks!
Title: lossyWAV 1.3.0 Development Thread
Post by: botface on 2011-01-19 09:16:38
My understanding, and I may be wrong, but nothing > -2.5 (i.e. portable has been ABX'd). I'd like to know the answer to this also. Certainly --standard (-q 5) so far is 100% transparent.

Yes, I think you're right. However, I've never seen any large scale listening test results, just ABX results from a handful (or less) of people. Has a large-enough scale test ever been done to establish statistically meaningful results?

I also agree with Googlebot that there doesn't seem much point trying to compete at typical lossy bit rates. But it does at least give people another choice
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-21 21:36:36
Unfortunately, there have been no large scale listening tests performed with lossyWAV. There have been, and still are, those who have volunteered their ears and time to test processed output at various stages in the development process - for which I am very grateful - the results have shaped the development of lossyWAV.

There may not be much point, to some, in trying to lower bitrates for "acceptable" output - on the other hand output at higher bitrates should have even more clearance between the signal and the added noise. The drive to lower bitrates, as has been said, gives people choice.

[edit] Sp. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: carpman on 2011-01-22 02:19:10
Finding out how far "down the quality scale [...] the apparent transparency point" is, seems very worthwhile IMO.

C.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-01-25 09:52:23
Nick, now that you're at 1.2.2z RC1 so that 1.3.0 is ahead of us: what about cleaning up the option scenery which has evolved during the development process?

My ideas on this as a whole (partially we talked about it already):

a) with the explicit exclusion of the --limit strategy it would be good IMO to have only the --altpreset quality scheme and forget about the older one.
    The --altpreset scheme allows for a good audio quality when varying q in steps of 2.5 as you always did for the named presets.
    Also bitrate scales well for a step size of 2.5 with the --altpreset scheme.
    q should be allowed to be in the range -2.5 to 10 (or maybe -5 instead of -2.5, but -2.5 as a lower limit is more in line with the lossyWAV target properties IMO).

b) analysis limit default should be the usual 16 kHz for q in the range q>=2.5, q<7.5.
    --limit should default to 15159 for q<2.5.
    --limit default should be 17 kHz or a little bit lower for q>=7.5.
    --limit should remain an explicit parameter to override the defaults.

c) Adaptive noise shaping should be defaulted as it showed to be useful and doesn't break things.
    However there should be a switch to turn it off.
    So this is the opposite to today's behavior where it has to be explicitly switched on.
    As for the -A value I have no idea what is most appropriate. Today it defaults to 64 if I see this correctly.
    I used a value of 96, but that was only because you suggested this some day for trying out. Encoding speed using -A 96 is fine to me.
    My feeling (from very few experiments) is that resulting quality doesn't depend much on the -A value.
    So the FIR quality parameter should go IMO (with the -A option as adaptive noise shaping should be defaulted) and should be appropriately set internally.

d) There should be named quality parameters which correspond to a -q stepsize of 2.5 used according to the default behavior as described by a) to c).
    Names can be similar to:
    - insane (equivalent to -q 10)
    - extreme (equivalent to -q 7.5)
    - standard (equivalent to -q 5)
    - economic (equivalent to -q 2.5)
    - portable (equivalent to -q 0)
    - superportable (equivalent to -q -2.5).
Title: lossyWAV 1.3.0 Development Thread
Post by: botface on 2011-01-25 11:45:33
Can someone help me with my Foobar parameters for Lossywav?

Please Ignore, I cracked it
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-25 18:19:38
@Botface - glad that you identified the issue....

@halb27 - I am thinking of stretching the -4 to 10 scale to -5 to 10. The only issues with --economic and --superportable are the associated letter for the short version as -E and -S are already used by --extreme and --insane.

I would also be looking for suggestions for for the new lowest quality setting as -Z, --zero could do with being changed.

I will post my initial proposals for the change to the --altpreset scale. I will not remove the existing preset scale but will introduce a --classic parameter to allow users to consciously select the old one.
Title: lossyWAV 1.3.0 Development Thread
Post by: botface on 2011-01-25 18:52:15
Just my £0.02 but I think negative quality settings look a bit silly. I'd much rather see 0 to10. But I accept that might result in the typical final bitrates not being smooth steps - and I like the idea of q5 being the "standard" or "assumed transparent" setting with roughly equal more and less conservative settings either side of it. Having said that I don't feel particularly strongly about it if you feel there's good reason to go -5 to 10
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-25 19:16:04
Another way to approach this would be to squeeze the portion of the quality scale currently between -5 and 5 into the 0 to 5 range. This would do away with negative quality values altogether but would have the side effect of bringing all of the quality presets lower than 5 closer together. I'll have a think on this too. Thanks for your tuppence worth.
Title: lossyWAV 1.3.0 Development Thread
Post by: carpman on 2011-01-25 19:20:35
Just a thought, but where minus numbers might be useful is where the scale cannot guarantee transparency.
If say --portable at -q 2.5 is transparent, but -q 2 is potentially not, then have --portable at 0 (or perhaps better 1) and < -q 2.5 at -1 onwards etc ..

C.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-25 19:29:40
Hmmmm.... I really quite like that suggestion. If this were to be developed then I would map the current -q 2.5 to -q 0, stretching 2.5 to 5 over 0 to 5 and moving -2.5 to 2.5 into -5 to 0.
Title: lossyWAV 1.3.0 Development Thread
Post by: carpman on 2011-01-25 19:51:29
The only thing I'd throw in (and I'm almost ambivalent about this) is what about not having 0 (zero).
e.g.  -2, -1, 1, 2, 3 ... (forget the numbers, but you see what I mean).
The reason I'm suggesting this, is if -x = potentially not transparent and +x = guaranteed transparency (with increasing safety margins*), what does 0 mean?

C.

EDIT *
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-25 19:54:32
Zero = the apparent transparency point? i.e. q>0, transparency expected; q<0, transparency not expected.
Title: lossyWAV 1.3.0 Development Thread
Post by: carpman on 2011-01-25 20:00:46
Yeah, that makes sense, especially since you're dealing with a point at the border of perceived transparency. So zero would be like the fulcrum.

C.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-01-25 20:06:39
... and +x = guaranteed transparency (with increasing safety margins*) ...
has me a bit nervous - "guaranteed" is a very strong word in this context. I would prefer to use "expected"
Title: lossyWAV 1.3.0 Development Thread
Post by: carpman on 2011-01-25 20:57:50
"guaranteed" is a very strong word in this context. I would prefer to use "expected"

Sensible. Do you think "guaranteed" can be used for --standard though? Since "expected" is also a relevant term for say LAME at -v 2. What it seems you are saying is "expected (even for problem samples)". And that kind of language would differentiate lossyWAV from many lossy transform codecs.

C.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-02-01 10:06:10
As for the named quality levels:

What about using three-letter-abbreviations like:

-INS
-XTR
-STD
-ECO
-PBL
-SPB ?
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-02-03 00:23:49
b) analysis limit default should be the usual 16 kHz for q in the range q>=2.5, q<7.5.
    --limit should default to 15159 for q<2.5.
    --limit default should be 17 kHz or a little bit lower for q>=7.5.
    --limit should remain an explicit parameter to override the defaults

Or maybe switch to 15159 for q<3.5 to smooth the bit rates as there was/is a (small) jump in the bit rates >2.5 where --impulse became default.
Anyway, all this might look different if the -q scale will be re-stretched and/or more defaults change.
I will post my initial proposals for the change to the --altpreset scale. I will not remove the existing preset scale but will introduce a --classic parameter to allow users to consciously select the old one.

Would that mean 3 sets of -q setting? normal, --altpreset, --classic ? I'm all for compatibility and I use the --alt-preset in 1.2.0 exclusively but I think if you give us a few hints of how the 1.3.0 -q scale relates to the 1.2.0 one we can figure out how to adjust our settings accordingly. I'm just thinking about maintainability in the future, so it's up to you.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-11 21:26:58
lossyWAV beta 1.2.3a RC2 attached to post #1 in this thread.

New default parameters introduced.

--limit as follows for default -q -5 to -q 10: 15159,  15332,  15504,  15676,  15848,  16021,  16107,  16193,  16279,  16365,  16451,  16538,  16624,  16710,  16796,  16882;

Approximate quality setting conversion as follows (in terms of resultant bitrate for my 10 album test set):
Code: [Select]
|-----------+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----|
|  default  |-5.00|-4.00|-3.00|-2.00|-1.00| 0.00| 1.00| 2.00| 3.00| 4.00| 5.00| 6.00| 7.00| 8.00| 9.00|10.00|
|-----------+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----|
|--altpreset|-2.52|-1.35|-0.24| 0.83| 1.95| 2.88| 3.80| 4.41| 4.90| 5.41| 5.93| 7.00| 8.08| 9.16|10.00|10.00|
|-----------+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----|
| --classic | 0.40| 0.86| 1.29| 1.75| 2.29| 2.89| 3.75| 4.27| 4.63| 5.01| 5.42| 6.25| 7.09| 7.95| 8.81| 9.68|
|-----------+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----|

Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-12 11:36:03
Need input:
1) Should the existing --altpreset preset system be removed now that the new default system exists?
2) Is the existing fixed noise shaping system required given that[blockquote]a) the new adaptive noise shaping seems to be working well;
b) the existing method only really works for 44.1kHz and 48kHz.[/blockquote]3) Should the default quality system automatically enable adaptive noise shaping?
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-02-12 12:25:48
To me the new default quality system including --limit defaults is very reasonable. Saying so I assume that the internal details of the new quality system are very similar to the internal details of the corresponding --altpreset setting - corresponding with respect to comparable bitrate. With this in mind the --altpreset scheme should be removed IMO. If it were me I wouldn't keep the classic scheme either. But it all depends on the internal parameters of the new default scheme not departing much from what we have with the --altpreset and current default scheme. Having just one quality scheme makes things a lot clearer.

The new quality system is defensive with respect to the quality systems used so far. If someone using current quality system with say -q 5 switches to the new system he will get a quality which will be equal or better.

I wasn't aware of sample frequency limitations of adaptive noise shaping. As for this I'd prefer a noise shaping parameter with 'adaptive' (default for 44.1 or 48 kHz), 'fixed', 'none' as possible values.

Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-12 12:53:44
Sorry, my lack of clarity.....

The fixed noise shaping method is only optimized for 44.1kHz and 48kHz (by the available coefficients).

[edit]
The adaptive noise shaping method copes with all permitted sample-rates (tested up to 192kHz so far).

With some more support for removing --altpreset (and, for that matter --classic) it will happen.

Seriously considering removing the fixed noise shaping method.
[/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: carpman on 2011-02-13 06:20:44
I'd be very happy with only one quality scheme (i.e. getting rid of --altpreset and --classic).
As far as noise shaping, I think on or off is good (so +1 for getting rid of 'fixed').

The simpler the better IMO.

C.
Title: lossyWAV 1.3.0 Development Thread
Post by: googlebot on 2011-02-13 13:33:36
Btw, have you experimented with 'pleasantness' of different kinds of noise besides hiding it as intelligently as possible?

For a lot of music, especially classical, a faint, mellow noise floor can sound much more pleasing than total silence in between. If I could trade-in bitrate for something like that, I would seriously consider it. But there are such and such noises, some annoy, some bed you gently.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-02-13 14:37:14
Thanks, Nick, for clarification that noise shaping limitations are with fixed noise shaping.

So for me: I'd give away fixed noise shaping (as well as --altpreset and --classic - under the assumption that internal details don't differ considerably from these with comparable bitrate).
The default quality system should automatically use adapitive noise shaping as a default IMO.
Title: lossyWAV 1.3.0 Development Thread
Post by: botface on 2011-02-13 18:46:37
I agree with halb27 (and others) about dropping  --altpreset and --classic. But I still think negative quality levels look a bit silly, even though I understand the rationale here.

In day-to-day English a quality level of zero is equivalent to having no quality at all. You'd expect anything with no quality to be pretty bad. Having a quality attribute that is even less than no quality is a bit nebulous to say the least but if such a thing could exist it must absolutely dire. I don't think that's the impression we want to create. What's more we know that this isn't the case with LossyWav so to me it doesn't make sense. However, as I've said before I don't feel strongly about it and if that's what others want I'm happy.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-02-13 19:42:49
...In day-to-day English a quality level of zero is equivalent to having no quality at all. ... Having a quality attribute that is even less than no quality is a bit nebulous to say the least ...


If it were me we could also give away -q levels and concentrate on named presets.
The new default scheme is a nontrivial change from the old schemes in terms of the meaning of the q levels. So to me it wouldn't be a bad thing to go on one step and switch to only named presets as a final solution.
Moreover the quality meaning of -q differences below a certain threshold is pretty uncertain anyway.

So in the end I think the clearest thing would be to have just named quality presets. Quality expectation should be clear from the name.
Once this final step would be made it would finish reasoning about the -q level scheme which has already undergone some history. With the maturity lossyWAV has reached I think it is appropriate to stop changing parameter systems right now.
And using just named presets would be a great step in this direction.

Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-02-13 23:30:41
If it were me we could also give away -q levels and concentrate on named presets.
The new default scheme is a nontrivial change from the old schemes in terms of the meaning of the q levels. So to me it wouldn't be a bad thing to go on one step and switch to only named presets as a final solution.

Not my opinion.
To me the named presets are meaningless, with names that suggest a specific use, which will not be the case for everyone. Also they're rather coarse (big steps in bit rate).
Having at least one working quality scale is a good thing, but I will leave it to others to discuss about the value range (<0 or >0).

I agree that the redefining of the Q scale will confuse the users that have not been following this thread. So the difference, between the scale in 1.2.0 and the new one, should be documented somewhere (maybe even in the longhelp).
Title: lossyWAV 1.3.0 Development Thread
Post by: carpman on 2011-02-14 01:02:28
To me the named presets are meaningless, with names that suggest a specific use, which will not be the case for everyone. Also they're rather coarse (big steps in bit rate).
Having at least one working quality scale is a good thing [...]

I agree.

C.
Title: lossyWAV 1.3.0 Development Thread
Post by: jetpower on 2011-02-14 17:22:32
I agree with halb27 (and others) about dropping  --altpreset and --classic. But I still think negative quality levels look a bit silly, even though I understand the rationale here.

In day-to-day English a quality level of zero is equivalent to having no quality at all. You'd expect anything with no quality to be pretty bad. Having a quality attribute that is even less than no quality is a bit nebulous to say the least but if such a thing could exist it must absolutely dire. I don't think that's the impression we want to create. What's more we know that this isn't the case with LossyWav so to me it doesn't make sense. However, as I've said before I don't feel strongly about it and if that's what others want I'm happy.


Regarding negative quality levels they could be made accessible only with additional special option, like --enable-advanced-options or --testing
Title: lossyWAV 1.3.0 Development Thread
Post by: Ljubo44 on 2011-02-15 02:18:52
What do you think. Which is the best possible command line for LossyWav.exe for 24bit / 96kHz wav conversion. I have used so far:
lossywav - -I --adaptive --silent --stdout          .. I get flac 8 after and getting about 950 kbps .. but I think it would be around 1300kbps in flac without much loss
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-16 21:08:14
What you used is the best possible - there is no higher quality setting, unless you wanted to add additional FFT analyses using --analyses <n> (3<=n<=5), or use the --underlap parameter to increase the number of FFT analyses carried out at each FFT length, --underlap <n> (n=4 or 8).
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-16 21:09:20
lossyWAV beta 1.2.3b RC3 attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: punkrockdude on 2011-02-16 23:59:27
I have encoded some HDCD tracks with quality 10, 9, 8, 7 and 6 and Foobar says they are HDCD still. How can this work when LossyWAV removes the lowest unused bits if I understand it correctly. Regards.

Edit: I notice when I play the files in Foobar the volume suddenly jumps up to normal after a few seconds indicating that it probably can't see any more HDCD info after a second or so.
Title: lossyWAV 1.3.0 Development Thread
Post by: bryant on 2011-02-17 02:22:49
I have encoded some HDCD tracks with quality 10, 9, 8, 7 and 6 and Foobar says they are HDCD still. How can this work when LossyWAV removes the lowest unused bits if I understand it correctly. Regards.

Edit: I notice when I play the files in Foobar the volume suddenly jumps up to normal after a few seconds indicating that it probably can't see any more HDCD info after a second or so.

I believe that what you are experiencing is something that I described here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=79427&view=findpost&p=720541). The problem is that because the beginning of the track is silence (or nearly so), LossyWAV is not removing any bits, so the HDCD signal is available. Once the music starts, bits are removed and the HDCD signal is lost and the decoder switches off the HDCD decoding. There might be very quiet passages later that might re-activate it. I have seen this with WavPack lossy encoding and real hardware HDCD decoders (but I think the foobar decoder will not do that).

The solution is not obvious. One might be that LossyWAV could have an option to destroy the HDCD signal if it is detected during a passage with no removed bits (just flipping one bit in the trigger sequence would do it, and there are only 10 per second, IIRC). Or someone could create a stand-alone program to destroy it for whole tracks before processing.

On the decoder plugin side, it might make sense to have the processor make a decision about the HDCD status of a track at the beginning and not allow it to change, but that's not ideal either (but would at least prevent switching off in the middle).

edit: spelling
Title: lossyWAV 1.3.0 Development Thread
Post by: [JAZ] on 2011-02-17 18:23:53
Maybe what it should do is detect the hdcd header and tell the user that the file has to be decoded by an hdcd bitstream first before feeding it to lossywav.

Then, a command line option could be added to skip this error and forcefully destroy the hdcd bitstream.

Not sure how much time this is worth.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-17 18:37:18
.... or when transcoding using foobar2000, the HDCD decoder plugin should be active when there is a chance of HDCD content being involved. I believe that it is the user's responsibility to ensure that the bitstream going into lossyWAV, or any codec / dsp for that matter, is going to be interpreted correctly.

I had a look at taking notice of HDCD content some time ago but it depends on calls to a Microsoft API and is therefore platform dependent (and also closed source on the part of the HDCD decoder....). Therefore I abandoned it.
Title: lossyWAV 1.3.0 Development Thread
Post by: Steve Forte Rio on 2011-02-17 19:38:20
Quote
-m, --midside        analyse 2 channel audio for mid/side content.


When and how this switch can be useful?
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-17 19:41:10
There was a request to include this analysis some time ago - there must be some type of content which has mid/side information incorporated into the L+R channels.
Title: lossyWAV 1.3.0 Development Thread
Post by: Steve Forte Rio on 2011-02-17 19:58:05
Sorry, I don't understand how lossywav processing and correlation of stereo channels can be related.

Anyway, should I add it to my command line? Can it improve/hurt processing quality or something else?
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-17 20:01:34
It will only work for stereo input and will link the bits-to-remove from each channel together, i.e. it will remove the lower derived number of bits from each channel. By default lossyWAV removes bits from each channel independently.

So, no - you should not be adding it to your command line.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-19 19:54:12
I completed yet another full collection transcode today (11493 tracks, 287GB FLAC, 882 kbps lossless) in about 16.5 hours. [edit] I should say that I used --superportable --impulse as my settings for this transcode - average bitrate overall 311kbps. The output is individual tracks, so the bitrate variation is a bit more extreme than if I had gone for one file per album. [/edit]

Out of interest I had a look at the spread of bitrates for the resulting files:
Code: [Select]
|-------------|-----|-----|-----|
|    Band     | Min | Avg | Max |
|-------------|-----|-----|-----|
|  0% to   5% |  54 | 240 | 276 |
|  5% to  10% | 276 | 283 | 287 |
| 10% to  15% | 287 | 290 | 293 |
| 15% to  20% | 293 | 295 | 297 |
| 20% to  25% | 297 | 299 | 300 |
| 25% to  30% | 300 | 302 | 303 |
| 30% to  35% | 303 | 304 | 306 |
| 35% to  40% | 306 | 307 | 308 |
| 40% to  45% | 308 | 309 | 310 |
| 45% to  50% | 310 | 311 | 312 |
| 50% to  55% | 312 | 313 | 314 |
| 55% to  60% | 314 | 315 | 316 |
| 60% to  65% | 316 | 318 | 319 |
| 65% to  70% | 319 | 320 | 321 |
| 70% to  75% | 321 | 322 | 324 |
| 75% to  80% | 324 | 325 | 327 |
| 80% to  85% | 327 | 328 | 330 |
| 85% to  90% | 330 | 333 | 335 |
| 90% to  95% | 335 | 339 | 343 |
| 95% to 100% | 343 | 363 | 608 |
|-------------|-----|-----|-----|

54 and 608 are extreme (the first is a Robbie Williams end of album track with a huge silence and the last is a live track).
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-21 19:31:10
I'm probably going to remove the --impulse parameter and enable it for all quality presets (currently if int(q)>0). This will only affect -5 to 0.99.. and will be able to be disabled by using --analyses 2 (default number of analyses will be 3).

The questionably named --reasonable preset will be changed to --intermediate as -i will be available when --impulse is removed.

I will also change the short parameter for --portable from -P to -p and for --postanalyse from -p to -P. In this way, --standard, --extreme and --insane will be -S, -E and -I respectively and --superportable, --economic, --portable and --intermediate will be -s, -e, -p and -i respectively.
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-02-22 09:36:21
I'm probably going to remove the --impulse parameter and enable it for all quality presets (currently if int(q)>0). This will only affect -5 to 0.99.
I used --superportable --impulse as my settings

So would that mean that the setting you used won't be possible anymore? Or is --impulse maybe also enabled with --analyses 3 ?

[oops] I read it again, --impulse will be always on. That would be alright with me. I just think the effect should be tested (on the lower -q's) and not be introduced in a final version.

Some other thoughts about the parameters you need for the presets:
If the only reason to remove this is to free up -i , you can also use any free symbol for --impulse you like. Alternatively you could at least keep the long --impulse.

To me it makes even sense to have all the numerous presets under 1 parameter preferable like -q [P|S|E|s|...] . If you think it is too tricky to combine alfa and numerical qualities it could be -p [S|E|I|s|e|p|i] as -p could be freed up. If you like, a long variant to match --preset standard,extreme,portable etc.

BTW I will not make a big thing of it (I know it's a can of worms), but now the quality scale has been stretched, I doubt that -q 5 is the sensible default. Just a quick idea: --standard = -q 2.5 (default) --high 5.0 . It might match the standard bit rates from the previous versions better.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-02-22 11:00:20
I like the idea of --impulse always being on. Makes things clearer.
And I like GeSomeone's idea of defaulting to new -q 2.5 calling this 'standard' and calling -q 5 'high'.
Moreover I like the idea of using the named presets as a value for the -q switch. Unifies things and allows for good names as there is no potential collision with other parameter names.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-22 20:42:16
Thanks for the constructive comments!

lossyWAV beta 1.2.3c RC4 attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-02-23 12:39:00
1.2.3.c's average bitrate for my usual test set of various pop music:

-q S: 432 kbps
-q P: 396 kbps
-q N: 338 kbps
-q X: 295 kbps

According to the description in the starting post I was afraid that the long names of the named presets are to be written '-q --portable' but was happy to see that it's '-q portable'.

I did a short listening test.
Using -q X eig was transparent to me, but I could ABX furious 9/10 (though quality is very good).
Using -q N furious was transparent to me.

As for the names of the named presets though it's not important:
I'd prefer to call -q -2.5 'portable' and -q 0 'intermediate' or 'economic'.
It would bring the two quality levels with 'portable' in their name together as the two worst (though excellent) quality levels.
This would match most what I'd expect from a 'portable quality': high quality leaving room for minor issues.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-23 19:18:53
Excellent news about -q intermediate - I'll swap portable and intermediate so the scale will now run: extraportable; portable; intermediate; standard; high; extreme; insane.

I am considering
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-02-23 19:36:42
Thanks, Nick, for exchanging 'portable' and 'intermediate'.

As for your further considerations: the new -A limits sound reasonable to me, and removing the option to disable adaptive noise shaping would be fine to me too.
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-02-23 21:58:43
The latest 1.2.3c seems like 4x slower (than 1.2.3b and 1.2.0).
Am I imagining this?

(Vista 32bit, Intel Core2 Duo E7300, libfftw3-3 3.2.2)
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-24 18:02:04
Adaptive shaping is now enabled by default - that would explain the difference in processing time.
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-02-24 22:30:29
Adaptive shaping is now enabled by default - that would explain the difference in processing time.

Is there a trade-of for this speed penalty? Or at the end of the day, what has improved in (upcoming) 1.3.x compared with 1.2.0.
I guess the real question is: what brings us ANS vs. no noise shaping?

As a side note: In the development leading to 1.2.0 there were indications that (the then used) noise shaping was a disadvantage when transcoding the lossyWav processed files to mp3 later. However, when it would be a real advantage for straight lossless to lossyWav, that would be more important.

[edit] rephrased a bit
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-02-26 09:22:31
The fixed noise shaping of 1.2.0 brings more noise to the very high frequency range. Because of mp3's sfb21 properties this makes mp3 encoding less efficient as a tendency.

Adaptive noise shaping doesn't do that.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-02-28 21:00:17
lossyWAV beta 1.2.3d RC5 attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: punkrockdude on 2011-03-01 02:49:57
I can only encode if I set no quality parameter. Weird. The same command line in Foobar2000 that worked before does not work at all with the new version. Regards.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-03-01 06:12:48
.... and the command line was?

[edit].... your command line probably contains text parameter relating to a specific quality preset. I would suggest that you have a look at the included help (lossywav -h). [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: Nowings69 on 2011-03-03 00:47:26
I can only encode if I set no quality parameter. Weird. The same command line in Foobar2000 that worked before does not work at all with the new version. Regards.
Code: [Select]
Past
Parameters: /d /c c:\"program files"\bin\lossywav - --quality standard --silent --stdout|c:\"program files"\bin\flac - -b 512 -5 -f -o%d --ignore-chunk-sizes

For Now
Parameters: /d /c c:\"program files"\bin\lossywav - -q standard --silent --stdout|c:\"program files"\bin\flac - -b 512 -5 -f -o%d --ignore-chunk-sizes

@Nick.C
I've using default preset since RC4,
and used -b 1024 in extreme for only 48kHz(LPCM) before it.
I hear a sound considerably changes in this candidate

Please let me hear your opinion for 48kHz(LPCM).
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-03-09 19:10:50
I hear a sound considerably changes in this candidate
Please let me hear your opinion for 48kHz(LPCM).
Could you please upload a 30 second (or less) sample of a / the track which is causing problems?
Title: lossyWAV 1.3.0 Development Thread
Post by: Ljubo44 on 2011-03-15 10:22:38
Nick. Can you add more options for higher quality of insane. This is result in bit compare plugin in foobar. File used: WAV 96kHz/24bit/2Ch (both channels are the same = mono)

FLAC 1753kb/s : No differences found
WavPack hybrid 1408kb/s :  Differences found: 38214905 sample(s), starting at 0.0000000 second(s), peak: 0.0000181 at 11.0004479 second(s), 1ch
WavPack hybrid 1208kb/s :  Differences found: 41685515 sample(s), starting at 0.0000000 second(s), peak: 0.0000347 at 47.1038021 second(s), 1ch
LossyWav 594kb/s : ______Differences found: 42549280 sample(s), starting at 0.0000000 second(s), peak: 0.0086710 at 80.6068333 second(s), 2ch
LossyWav 555kb/s : ______Differences found: 42554737 sample(s), starting at 0.0000000 second(s), peak: 0.0154066 at 80.9439896 second(s), 1ch

LossyWav 594kb/s : (/d /c C:\bin\lossywav - --insane --adaptive --underlap 8 --silent --stdout|C:\bin\flac - -b 512 -8 -f -o%d --ignore-chunk-sizes)
LossyWav 555kb/s : (/d /c C:\bin\lossywav - -I --adaptive --silent --stdout|C:\bin\flac - -b 512 -8 -f -o%d --ignore-chunk-sizes)
Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2011-03-15 11:00:54
Insane is already, er, insane.

If you want more, the only "sensible" option is to simply keep x more bits than suggested, or offset the threshold by x dB. Both have the same effect (the latter gives finer control).

Other options include enforcing a minimum number of bits to keep.

These have all be played with in the past (don't know if any are left in there as hidden features), but the current presets are felt to be more useful.

What are you trying to do?

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nowings69 on 2011-03-16 06:21:46
I hear a sound considerably changes in this candidate
Please let me hear your opinion for 48kHz(LPCM).
Could you please upload a 30 second (or less) sample of a / the track which is causing problems?


Well,precisely I dont remeber?when did it change since
because  it does not overwrite Writing Library
My all LPCM trusts your ear?as LossyWav

After the next time, I do not neglect preparations so that it is not asked a question symbolic entirely




Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-03-16 20:39:56
I had a look at the adaptive noise shaping method again - from the point of view of sample-rates greater than 44.1kHz and I have made a few minor alterations. I believe that these are for the better but am reverting to simple beta rather than release candidate.

I am thinking about how best to allow the user to tweak certain parameters to further reduce the number of bits removed. One which immediately springs to mind is to allow the user to increase the minimum-number-of-bits-to-keep (default=6), probably user selectable between 7 and 16. Will revert with another beta in due course.

lossyWAV beta 1.2.3e attached to post #1 in this thread.

Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-03-17 20:40:23
1.2.3.e's average bitrate for my usual test set of various pop music:

-q S: 431 kbps
-q C: 395 kbps
-q P: 337 kbps
-q X: 293 kbps

Using -q X I could ABX eig and furious both 9/10. The hiss in eig is relatively obvious.
Using -Q P I could not ABX eig (the improvement from -q X is quite impressive), and ABXed furious 8/10. Don't care too much about artificial furious, especially as I'd call the result good.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-03-17 20:49:13
Thanks for the very prompt testing - these results seems to be a retrograde step from 1.2.3c (the last for which I could find your test results).

I will look at the differences in the noise shaping between these versions and revert.

I have decided to include a new parameter "--static" in the next beta to allow the user to increase the minimum-number-of-bits-to-keep as mentioned previously.

[edit] sp. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-03-17 21:50:52
... these results seems to be a retrograde step from 1.2.3c ...

Well, when ABXing at different times my ABX results are not necessarily comparable. I guess my sensitvity varies. Moreover the exact test details aren't exactly the same (especially listening volume).
So I retested eig and ABXed it against the 1.2.3.c and 1.2.3.e extraportable results. And yes, the 1.2.3.c result is really better.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-03-18 09:50:23
I did the same test again this morning as with my last post, and I could ABX eig using 1.2.3.c -X with the same result as when using 1.2.3.e.
My sensitivity really changes. Not good, but it is like that. Probably also due to my age (61). It would be great if we could have more testers.
Sorry for the confusion.
Title: lossyWAV 1.3.0 Development Thread
Post by: Ljubo44 on 2011-03-19 17:08:50
I am thinking about how best to allow the user to tweak certain parameters to further reduce the number of bits removed. One which immediately springs to mind is to allow the user to increase the minimum-number-of-bits-to-keep (default=6), probably user selectable between 7 and 16. Will revert with another beta in due course.

lossyWAV beta 1.2.3e attached to post #1 in this thread.


Awesome thank you. Your thread is my homepage
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-03-24 21:34:00
lossyWAV beta 1.2.3f attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-03-29 08:53:10
I tested 1.2.3.f in my usual way.
Average bitrates are:

-q S: 432 kbps
-q C: 397 kbps
-q P: 340 kbps
-q X: 298 kbps

Using -q X I could not ABX eig. With furious I arrived at 8/10. For sec. 1.8...2.8 the added hiss makes the result sound a tiny bit brighter. It's only a tiny bit we really shouldn't care about with this artificial sample.
Using -q P my result with this spot was 6/10.

I also listened to some -q X encoded regular music and was totally happy with the result.
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-03-29 11:36:25
Thanks halb27 for your prompt test.
Did anybody test other sample rates than 44.1k? Just asking because Nick did not go final because of a suspicion there.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-04-08 20:51:07
I've been working with higher sample rates - with somewhat mixed success.

The adaptive noise shaping method seems to be working well for sample rates up to and including 96kHz. Above that however, there are issues that I have not yet managed to get to the bottom of.
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-04-10 19:00:50
The adaptive noise shaping method seems to be working well for sample rates up to and including 96kHz.

For all practical purposes that would do. Personally, if I wanted to save space on a 192kHz file, the first thing I would consider is resampling to 96kHz 
I understand, of course, that you'd like to know what goes on at higher rates, if not, you could set 96kHz as the maximum sample rate for 1.3.0.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-04-12 18:53:15
Knowing why is pretty fundamental - and working it out can cause some previously undetected problems to be discovered and rectified....

lossyWAV beta 1.2.3g attached to post #1 in this thread.

I believe that the adaptive noise shaping is working for all sample rates up to and including 384kHz (maximum tested so far....).
Title: lossyWAV 1.3.0 Development Thread
Post by: botface on 2011-04-13 10:18:11

I noticed that the Wiki looks badly out of date - especially regarding recent changes to quality settings - but I don't feel confident to update it
Title: lossyWAV 1.3.0 Development Thread
Post by: Ljubo44 on 2011-04-13 16:43:10
lossyWAV_beta_1.2.3g is twice better than lossyWAV_beta_1.2.3e at 96kHz    from 1235kb/s to 1244kb/s but twice closer to original. congrats!
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-04-13 18:36:14
That's one positive response, thanks! Anyone else care to chip in with some high-sample-rate observations?

I will get around to the wiki when v1.3.0 is (finally!) released (although I will need help, as usual.... ).
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-04-13 19:45:48
No high sample rate test from my side, just my usual one with the usual results (furiuos ABXable with -q X though quality is good, furious and eig fine with -q P).

Bitrates for my standard test set:

-q S: 436 kbps
-q C: 399 kbps
-q P: 341 kbps
-q X: 297 kbps
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-04-13 21:50:55
Thanks again for testing - it's much appreciated as always.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-04-16 17:39:37
lossyWAV beta 1.2.3h attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-04-17 19:45:27
Thinking of reducing maximum clips-per-channel-per-codec-block to zero when adaptive shaping is active to reduce the possibility of the current method which allows a certain number of clips from "overloading" the noise-shaping filter(s).
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-04-21 19:13:27
Two technical questions:

1) the spreading algorithm in lossyWAV has always averaged the amplitude of adjacent FFT results rather than the power - is this likely to be the correct approach?

2) Should I correct the audio for DC offset prior to performing the FFT analyses on it (DC offset correction over number of samples in each FFT only, repeated per FFT)?

[edits] .... due to poor command of the English language.... [/edits]
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-04-22 19:33:44
lossyWAV beta 1.2.3i attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-04-23 19:02:27
Full collection transcode resulted in 303kbit/s at -q X.
Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2011-04-26 14:56:05
Two technical questions:

1) the spreading algorithm in lossyWAV has always averaged the amplitude of adjacent FFT results rather than the power - is this likely to be the correct approach?

2) Should I correct the audio for DC offset prior to performing the FFT analyses on it (DC offset correction over number of samples in each FFT only, repeated per FFT)?

[edits] .... due to poor command of the English language.... [/edits]

1) probably not  down the route to proper psychoacoustics you go...

2) you don't use the DC bin in the calculations, do you? if no, then no need to worry (IMO! I could be wrong). if yes, then don't.

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: Ljubo44 on 2011-04-26 18:13:57
lossyWAV beta 1.2.3h is better than lossyWAV beta 1.2.3i      because lossyWAV beta 1.2.3i have stronger supression noise in audible range. In lossyWAV beta 1.2.3h the situation is reversed. But better is to be supression noise in inaudible range. I speaking only for high sample rate, 192kHz and 96kHz
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-04-26 18:42:25
I speaking only for high sample rate, 192kHz and 96kHz
Thanks for that - I'll have a look. I'm trying to optimise file-size as well as noise-shaping. It's disappointing to hear that beta 1.2.3i is retrograde compared to beta 1.2.3h.

David:

1) I think that I phrased my question badly. Should I be using power averaging?

2) The DC bin is not used in the calculations. Correcting DC offset seems to have got rid of the problem that has been plaguing the Furious sample. I can only guess that this is because of lower calculated amplitudes at the low frequency end of the spectrum. This alone makes me think that I need to correct before FFT. I'll try some other things that have occurred.
Title: lossyWAV 1.3.0 Development Thread
Post by: Ljubo44 on 2011-04-26 23:10:14
picture says more than 1000 words

lossyWAV_beta_1.2.3h
(http://s3.postimage.org/ud3vfv5w/LW123h.jpg) (http://postimage.org/image/ud3vfv5w/)

lossyWAV_beta_1.2.3i
(http://s1.postimage.org/15660ivus/LW123i.jpg) (http://postimage.org/image/15660ivus/)

I using wavelab6 for audio compare between original and lossywav and gain for inverted difference +50db. All settings is [ lossywav - -q 10.0 --static 16 --silent --stdout ]
I still using lossywave for testing only. I hope this will help you
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-04-27 11:26:23
lossyWAV beta 1.2.3i have stronger supression noise in audible range.

I using wavelab6 for audio compare between original and lossywav and gain for inverted difference +50db.

It seems to me that you only looked at the difference signal, this tells not all without showing the source signal. It could be that lossyWav(version i) is "hiding" the introduced noise better "behind" the source signal.
At the end of the day the only thing that counts is, whether the noise is (more) audible?
Title: lossyWAV 1.3.0 Development Thread
Post by: Ljubo44 on 2011-04-27 12:18:33
lossyWAV beta 1.2.3h is best codec ever. 1200kb/s from lossywav is Better than wavpack hybrid at 1600kb/s because in silence lossywav added noise , and, where audio signal is available, that is not changed. In wavpack hybrid situation is reversed. Silence is unchanged but audio peaks in higher band is changed.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-05-02 08:25:24
Back from holidays I see more development has been going on.
I just tried furious and eig with new i version using -Q X.

I'm sorry to say that this is a quality regression. furious is easily ABXable in the sec. 0 ... 0.8 range (and I wouldn't call it acceptable as I did with the previous versions tested). And I ABXed eig 9/10 though this wasn't easy for me as I'm pretty insensitive to temporal smearing. I must say though that also with version g I had a slight suspicion that eig wasn't totally fine but this belief could not be backed up at all by my ABXing, so it didn't have any meaning.
Title: lossyWAV 1.3.0 Development Thread
Post by: Ljubo44 on 2011-05-02 14:28:00
The world need a codec to compress 24-bit audio in HR sample rates like QTAAC on 16-bit 44,1kHz (-tvbr 127). Where the silence is to add noise, Where the audio is to leave unchanged. No exist that codec yet. I hope in the next versions in LossyWav.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-05-03 16:48:40
I'd like to try version b1.2.3h.
Can somebody give me a link to it, please?
Title: lossyWAV 1.3.0 Development Thread
Post by: Ljubo44 on 2011-05-03 16:52:13
http://www.speedyshare.com/files/28274728/...beta_1.2.3h.rar (http://www.speedyshare.com/files/28274728/lossyWAV_beta_1.2.3h.rar)
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-05-03 19:55:44
Thanks a lot.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-05-03 20:21:06
@halb27:

Could I ask you to please test 1.2.3i using the --nodccorrect parameter? This would allow me to rule out (or in) the recent DC offset correction.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-05-04 10:01:52
I just had a few minutes where it was quiet at my home (a problem at the moment) and tested version i -Q X --nodccorrect with furious. Again it was very easily ABXable 10/10.
The --nodccorrect version BTW has a lower bitrate by 20 kbps for furious.
I hope I get more quiet moments today and would like to test version h and other previous versions in direct comparison.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-05-04 17:23:09
Finally it was quiet around here.
I tested versions c, f, g, h, i, i --nodccorrect for furious in an immediate sequence.
Quality of versions f, g, h, i, i --nodccorrect is about the same, so no regression from g to i. I'm just more sensitive to furious at the moment.
But version c of furious was harder to ABX for me than were the other versions.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-05-04 20:55:44
lossyWAV beta 1.2.3j attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-05-05 08:25:13
Nick, you're great at creating heuristics for improving quality!

Version b1.2.3.j -Q X is excellent with furious (I ABXed it 7/10, and I compared it with the version i result which is real bad in comparison).
I could not ABX eig, though it would be great if someone else could try this (can't get rid of a slight suspicion but I am not the one to ABX it).

Average bitrate of b1.2.3.j -Q X for my standard test set is 303 kbps.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-05-06 21:17:52
lossyWAV beta 1.2.3k RC1 attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-05-08 17:18:40
I see some quick developments now.

Nick, in the version below you introduced --limit defaults to the (new) standard quality scale,
lossyWAV beta 1.2.3a RC2

I was wondering if those values change depending on the sample rate? (common case 48kHz vs. 44.1kHz) and if that would make any significant difference.

BTW I will regard the current version RC6 myself .
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-05-08 19:34:00
BTW I will regard the current version RC6 myself .
Point taken

The upper limit for determination of allowable bits-to-remove (i.e. noise-to-add) does not change with sample-rate, only quality preset. The user can opt to increase the upper limit to a maximum of 20kHz.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-05-09 08:12:00
I just tried version 1.2.3k in direct comparison to 1.2.3j using -Q X on furious and eig, as usual.

For furious using version k I arrived at 6/6 which turned into a 7/10. With version j for comparison I arrived at 5/5 which turned into a 8/10.
I'd judge the two versions to be very good to the same degree on furious.

For eig using version k I arrived at 5/5 which turned into a 9/10. With version j for comparison I stopped at 1/4 as I clearly can't ABX it.
To me version j is clearly superior on eig.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-05-09 20:48:14
@halb27 - thanks again. There was a "bug" in 1.2.3j - although it seems to be beneficial to eig.

lossyWAV beta 1.2.3l RC7 attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-05-10 08:24:06
Using 1.2.3.l -Q X I couldn't ABX eig nor furious (6/10 in both cases).

Using version k for comparison I also couldn't ABX them (furious: 7/10, eig: 3/10).

Obviously I am less sensitive today to temporal smearing (varying sensitivity is gonna be a major problem for me) so this isn't very meaningful. I'll try again and report when I am able to ABX eig with version k again.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-05-11 22:33:01
lossyWAV beta 1.2.3m RC8 attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: Batman321 on 2011-05-12 00:08:42
Sorry to ask, but why do we need lossy wav or lossy flac?
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-05-12 08:53:17
There's no such thing as 'we need or don't need lossyWav'.
If you want lossless encoding: use a lossless codec, you don't need lossyWav.
If you want lossy encoding: you can use any lossy codec according to your needs, quality is excellent even when using good old mp3 with high bitrates, so you don't need lossyWav either.

But lossyWav is an enrichment to the world of lossy encoding:

- other than the with usual transform codecs where the musical information is transformed from the time to the frequency domain with codec specific limitations and a lot of heuristic decision making with their potential flaws on specific occasion, the lossyWav signal path is very simple reducing just the number of bits per wave sample. However - though to a minor extent - heuristics is done too, and is relevant especially at the lowest quality settings.

- if you use the standard quality or above, probability of audible issues is extremely close to zero. In a sense you get lossyWav preprocessed FLAC files with the quality of lossless FLAC files but smaller file size. Again this is not totally different from the world of other lossy encoders where you find yourself in a similar or the same situation when using very high bitrates, especially if the codec allows for extremely high bitrates like AAC does.

- from the encoding principles lossyWav + a lossless codec cannot be compared well with a transform codec but much better with the lossy variant of a lossless codec, most notably wavPack lossy. The advantage of lossyWav here is that you have a choice of the final codec, and with FLAC a widely supported codec is available which works very well together with lossyWav. Moreover quality control is supposed to be better with lossyWav than with wavPack lossy, though at extremely high bitrate this isn't much of a concern.

- as lossyWav is a preprocessor to a lossless codec like FLAC, you can always losslessly transcode the say lossyWav + FLAC result to another losseless codec like say TAK some day later in case this turns out to be useful for whatever reason, for instance when the new codec is more widely supported on players, or if it is more efficient.

lossyWav just adds to your choices. And as it isn't just another of the many transform codecs it's a very welcome addition IMO.
Title: lossyWAV 1.3.0 Development Thread
Post by: Batman321 on 2011-05-12 19:17:31
That's exactly what I wanted to know, thanks 
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-05-13 18:07:35
lossyWAV beta 1.2.3n RC9 attached to post #1 in this thread.

(I think this may just be the one....)
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-05-16 20:25:27
lossyWAV beta 1.2.3o RC10(!) attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-05-17 10:31:29
I tested furious and eig using -Q X.

I ABXed 1.2.3o for furious 8/10 and  eig 4/10. Quality is excellent, even furious testing was hard.
Results for 1.2.3m were the same in a practical sense (furious 7/10 [but I don't think version o is worse], eig 4/10).

For a comparison I tested version j on furious which came out fine in an earlier test: 7/10, but to me version 1.2.3o is a tiny bit better (with version j there were more situations when I was pretty sure I heard a difference and I was right, with version o it was more of a guessing throughout though successful most of the time).
For another comparison I tested version k on eig which I was able to ABX in an earlier test. Again I did not succeed: 5/10.


Nick, my impression is: lossyWav has matured so much that further minor modifications are not worth while, at least at the moment. What's really lacking is reassuring quality on a broader basis. Though this seems to be a problem anyway I think as long as there aren't very promising new ideas it's best to really stick to the latest version (or the next one if you have already something new in mind), and to clearly say so that this is the release candidate.
Hopefully this may invite more testers to participate.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-05-17 18:38:34
Unless I trip up on any bugs in the code, I will not be changing anything between RC10 and final release of 1.3.0.

Thanks (yet again) for the testing - encouraging results!
Title: lossyWAV 1.3.0 Development Thread
Post by: zorzescu on 2011-05-17 21:25:50
Hi, as I have been using lossyWAV/FLAC almost from the begining (currently lossyWAV 1.2.0) for my FM radio archives. I decided to check the last 1.2.3 RC10. My typical 1.2.0 command line switch is only --altpreset and q. For my purpose I decided to use q=3.3 witch gave me compression ratio about 0.3 (compression 70% of the original WAV), and bitrate about 430 kbps. Complete process of compressing a 50 minutes file lasts for 50 seconds (lossyWAV + FLAC).

Now, as I checked  lossyWAV 1.2.3o RC10 I realized that I should use q -1.5 to have 430 kbps in the resulting FLAC. What more preprocess time rises to about 2 minutes 50 seconds, that is almost 3 times longer than for version 1.2.0!

What would be the advantage of using version 1.3 vs 1.2 when the resulting efects for the given bitrate are (?) comparable, but preprocessing runs 3 times longer then in lossyWAV 1.2.0?
I think I should stay with lossyWAV 1.2.0. Am I right?
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-05-17 21:34:59
The quality preset system has been revamped - --standard is now -q 2.5; --portable is now -q -2.5.

The extra processing time is due to the adaptive noise shaping (which involves the creation and application of one 64-tap FIR filter per channel, per codec-block). This takes time.

Adaptive noise shaping does, however, change where the added noise due to bit removal (i.e. rounding off lower significant bits) goes. With no adaptive noise shaping the added noise is white and is applied pretty much evenly across the spectrum. With adaptive noise shaping the added noise is reduced in the audible range and enhanced above the audible range.

You could use 1.3.0 using "--adaptive off" - but you would probably be fine sticking with 1.2.0.
Title: lossyWAV 1.3.0 Development Thread
Post by: zorzescu on 2011-05-17 21:56:05
Thank you, Nick, for quick explanation
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-05-18 20:01:00
Full transcode of my collection, using beta 1.2.3o RC10 --quality extraportable --maxclips 0, results in 309kbit/s / 104GiB (lossless source 882kbit/s / 299GiB).
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-05-24 18:53:25
50 downloads and no adverse comments - should I take this as a good sign?
Title: lossyWAV 1.3.0 Development Thread
Post by: Ljubo44 on 2011-05-25 12:45:05
Yes, I tried all possible RC.. For me, the best is RC8. Closest to the original.
Best ratio (quality / size)
24bit/96kHz - lossywav - -q 10.0 --static 19 --silent --stdout | Takc -e -p4m -fsl16384 -ihs
16bit/44kHz - lossywav - -q 3.0 --static 16 --silent --stdout | Takc -e -p4m -fsl2096 -ihs
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-05-25 20:08:08
Can you give us those parts of the tracks on which you can hear differences to the original?
Title: lossyWAV 1.3.0 Development Thread
Post by: Ljubo44 on 2011-06-02 00:10:54
Forget all what i said. Finally i decided to convert to lossless only. (becauce i not want to hear difference, even any piece of sample Diversity in audio)
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-06-02 19:29:20
Are you saying that you have successfully ABXed 24 bit 96kHz? If so, please provide a sample.

What you said is not so easily forgotten as you have made (as yet unproven) allegations regarding lossyWAV output created at settings which have been (up to now) considered to be transparent (due to lack of evidence to the contrary).
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-06-14 20:30:30
How does it look for a final 1.3.0? More bug hunting?
No problems with casual use here.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-06-14 20:44:43
Most of the last few weeks has been devoted to the presentational side of output. I have put in place a new parameter -W, --width which allows the user to select the maximum width of various output information in the range 80 to 255 characters.

Prompted by Woodinville's histogram related post (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=88836&view=findpost&p=757280), I implemented a simple sample value count which outputs a histogram 64 bins wide.

Some major structural changes in the way the determination of bits-to-remove processing itself is carried out have been implemented - I'm much happier with the code now.

A few changes have been made to the adaptive noise shaping method. After reading the development thread again I have taken both the short FFT (default=64 samples for 44.1/48kHz) and long FFT (default=1024 samples for 44.1/48kHz) results into account when creating the desired shape of the filtered noise. This has had a few knock on effects on the code but no real impact on processing speed. The noise difference in critical samples (eig, furious) is (I believe) improved using this variant.

These small changes necessitate a small final beta test - volunteers?
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-06-14 20:52:39
Thanks for the update. Sorry, I don't trust myself with ABX.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-06-14 22:17:49
lossyWAV beta 1.2.3p RC11 attached to post #1 in this thread. I sincerely hope that this is the last RC.
Title: lossyWAV 1.3.0 Development Thread
Post by: darkbyte on 2011-06-15 00:20:16
First of all, thank you for this wonderful program.
My question is not close related to the development but as i see the creator of WavPack is also reading this topic so maybe this is the best way to ask you both.
To get to the point: i'm considering to encode my lossless collection into lossyWAV in hybrid mode. As far as i know i have to say during encode that i need a correction file and i have to encode the correction file also into some kind of lossless format (eg. FLAC). My biggest problem with this is that none of the PC software players can use these correction files currently. I have to do the restoration manualy if i need the original file.
On the other hand, i had some tests with WavPack hybrid lossless, and it works fine with Foobar and even with Winamp. If the correction file presents the player decodes the audio in lossless mode. Without the correction file i can listen to the lossy part (this way i can quickly copy some music to my Android phone without encoding anything). I'm wondering is it possible to feed the lossy and correction WAVs produced by lossyWAV to WavPack somehow to encode a WV/WVC pair or the lossy and lossless part encode algorithms are so sticked together in WavPack that this can't be done? This way you could use lossyWAV to produce the lossy/lossless part (with all of the improvements and the quality based mode) but you also have the compatibility of the WavPack hybrid format.
Title: lossyWAV 1.3.0 Development Thread
Post by: bryant on 2011-06-15 04:40:08
My question is not close related to the development but as i see the creator of WavPack is also reading this topic so maybe this is the best way to ask you both.

What you are asking for makes sense, but (as you guessed) the algorithm for WavPack hybrid is not compatible with lossyWAV.

It would be possible to port the algorithm in lossyWAV that calculates “bits to remove” and create WavPack hybrid files that were equivalent to lossyWAV, but they would not actually have the LSBs zero like lossyWAV does, so you would lose the clever advantage of lossyWAV audio that it can be unpacked and compressed equally well with another lossless codec. Also, the adaptive noise shaping would not port directly (WavPack’s adaptive noise shaping is much simpler).

That said, if you like the way the WavPack correction file can be used by various players, why not just use WavPack hybrid mode? It does not adapt the bitrate to the actual audio like lossyWAV does, but I believe that WavPack still gives somewhat higher quality for the same bitrate. If you use a bitrate of 384 kbps for 16/44 audio it should always be transparent, and that can’t be much greater than the average you are getting from lossyWAV.
Title: lossyWAV 1.3.0 Development Thread
Post by: darkbyte on 2011-06-15 08:43:52
why not just use WavPack hybrid mode?

I do so. However i don't like the idea to encode with an average bitrate. I already made a mistake in the past with using ABR MP3.  I'm using a 4bit/sample WavPack encoding setting for the lossy part now. It's only a matter of taste, it would be better for me to use a constant quality setting, at least it seems that bitrate fluctuates much more with a lossyFLAC file, than with a WavPack.  I know that setting post processing on WavPack encoding do some bitrate boost on cricital samples (i'm using x3 as suggested in the documentation)
I would sacrifice the lossless transcoding capability of the lossy part if i could store lossyWAV files in a "working" lossy+correction form. However as you describe this is already a lot of work to do.
Title: lossyWAV 1.3.0 Development Thread
Post by: 2Bdecided on 2011-06-15 14:01:41
@darkbyte,

it sounds like a good question for the fb2k developer(s) - "can you support lossyFLAC+correction files please?"

some talented person could even make an input plug-in for Winamp.

It's "just" finding the correction file (if it exists) that corresponds to the current file, ? verifying it really does match ?, launching a second FLAC (or whatever) decode, and adding the results to the file that's already being decoded. And handling everything that you currently have to handle once (e.g. seeking), twice simultaneously and in sync.


If you're using FLAC for example, this would be a replacement FLAC decoder (that would fall back to standard FLAC decoder when there was no correction file, and when the input wasn't lossyWAV).

It may be worth considering if there's a more efficient way of doing this (and/or a more efficient way of storing correction date) before programming this.

Cheers,
David.
Title: lossyWAV 1.3.0 Development Thread
Post by: darkbyte on 2011-06-15 16:46:09
it sounds like a good question for the fb2k developer(s) - "can you support lossyFLAC+correction files please?"

Okay, moved my question there  I found a similar topic here (http://www.hydrogenaudio.org/forums/index.php?showtopic=77920). It was created more than a year ago and there's no reply at all. Hopefully it could catch more attention this time.
Title: lossyWAV 1.3.0 Development Thread
Post by: RastaMan on 2011-06-16 23:35:41
Don't like the --altpreset switch being eliminated. Also don't like the "new & improved" (AKA "Slow") adaptive noise shaping method. Telling somebody, also, to just turn it off isn't great, either. White noise getting applied "pretty much evenly across the spectrum" just isn't good enough. Compared to the official version, LossyWAV 1.3.0 comes off as a downgrade. Especially when I can use v1.2.0 to create files using the --extreme --altpreset --shaping switches to produces files that cut file sizes in half and give me the high quality transparency that I want, with encoding speeds that are 50% faster.
Title: lossyWAV 1.3.0 Development Thread
Post by: mezenga on 2011-06-17 02:02:28
White noise getting applied "pretty much evenly across the spectrum" just isn't good enough

I think you misunderstood the effect of the adaptive noise shapping. See bellow:

With adaptive noise shaping the added noise is reduced in the audible range and enhanced above the audible range.

Nobody is saying that 1.3.0 suites you better and, repeating what Nick.C said, "you would probably be fine sticking with 1.2.0".
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-06-18 21:50:14
Don't like the --altpreset switch being eliminated. Also don't like the "new & improved" (AKA "Slow") adaptive noise shaping method.

The --altpreset lost it's meaning (in the new version) as all presets are newly tuned and the quality scale has changed. It would be more confusing to have old and new quality scales and trying to bring those into some kind of relation. Apples and Oranges kind of thing.
The speed penalty for Adaptive Noiseshaping is maybe unfortunate, but at least Nick is trying to push the limits of the lossyWav method. I suppose it's up to you if you'd like to stick with 1.2.0.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-06-18 22:27:53
.... but RastaMan's comment has prompted a potential development:

to implement a fixed shaping method which would disable adaptive noise shaping and

- use the old fixed noise shaping; [not my preferred option]

or

- use a newly implemented FIR version of Sebastian G's IIR shaping method (using the new method of bit-removal with FIR shaping). [my preferred option]
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-06-19 21:41:22
Finished a full collection transcode using beta 1.2.3p RC11 with "-q X --maxclips 0" resulting in 307kbit/s (from 882kbit/s lossless FLAC).
Title: lossyWAV 1.3.0 Development Thread
Post by: halb27 on 2011-06-20 15:49:49
I tested 1.2.3p RC11 -q X in my usual way.
With eig I arrived at 6/7 which turned into 7/10.
With furious, sec. 0 ... 0.8, I had no chance and stopped at 1/5.
With furiuos, sec. 1.9 ... 2.8, I arrived at 4/4 which turned into a 7/10.
So, as with more or less all my latest tests, I can't ABX my usual problem samples, though I guess people with better ears are able to ABX at least eig.

Anyway, for -q X it's a great result to me.
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-06-20 19:35:24
Thanks very much for that - I am now happy that the adaptive shaping in beta 1.2.3p RC11 is "final" and the rest of the code just needs final polishing before the release of 1.3.0.

Further to RastaMan's comment regarding fixed noise shaping:

1) I have implemented the method by which a 64 tap FIR filter can be used to perform fixed noise shaping using the same bits-to-remove code as for adaptive noise shaping (but obviously with a constant rather than variable filter);
2) I am working on how much of this shaping to apply for each of the quality presets (v1.2.0 used shaping_factor=q/10 for q=0 to 10; shaping_factor was zero for negative quality values on the altpreset scale).

[edit] It is worth noting that the use of an FIR filter for fixed noise shaping (although slow) allows the desired gain curve to be used to create a filter for the same sample-rate as the audio. The old fixed noise shaping only had coefficients for 44.1kHz and 48kHz - it did not work properly for any other sample-rates. [/edit]
Title: lossyWAV 1.3.0 Development Thread
Post by: Native_Soulja on 2011-06-22 21:59:26
What settings is everyone using for LossyFLAC? I want to use some non default settings and was wondering what other possible settings are there?
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-06-22 22:21:08
Why do you want to use some non-default settings?

There are seven presets and 15001 possible steps on the quality scale....

Use "lossyWAV -L" to display long help.
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-06-28 14:11:07
What settings is everyone using for LossyFLAC?

I usually choose -q 0 to -q 1  with  --limit 15159 added. But that's just a personal preference with no big science behind it and those values seem to match the --altpreset 3 I used with 1.2.0 .
In short, instead of the default (-q 2.5), your best bet is to use the -q (--quality) scale to find bitrates your happy with and check that you don't hear a difference (might depend on what you use the result files for).
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-07-23 15:43:02
Well - nearly 6 weeks since the release of beta 1.2.3p RC11 and no bug reports....

I'll get on with tidying up the code in preparation for release!
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-08-06 21:50:52
lossyWAV 1.3.0 attached to post #1 in this thread.
Title: lossyWAV 1.3.0 Development Thread
Post by: lvqcl on 2011-08-06 22:29:18
Thanks for the development. BTW, I noticed that both lossyWAV_1.3.0.zip and lossyWAV_Source_20110806_1.3.0.zip contain LossyWAV.exe, and they are different...

(and, if someone doesn't know: FFTW 3.3 was released 2 weeks ago)
Title: lossyWAV 1.3.0 Development Thread
Post by: Nick.C on 2011-08-06 22:40:53
Executable replaced in lossyWAV_1.3.0.zip.

Last time I looked, FFTW 3.3 was still in beta - my omission for not checking again. lossyWAV is compatible with FFTW 3.3.
Title: lossyWAV 1.3.0 Development Thread
Post by: GeSomeone on 2011-08-07 17:32:57
Congrats Nick, for reaching another milestone.
I guess thread should be closed after a while to avoid confusion, bug reports (if any) and test results can be new posts in this forum.
Title: lossyWAV 1.3.0 Development Thread
Post by: greynol on 2011-08-07 20:01:08
To satisfy the request of the developer, this discussion will now close in order to "encourage discussion regarding the release of 1.3.0 to take place in different threads."
SimplePortal 1.0.0 RC1 © 2008-2019