IPB

Welcome Guest ( Log In | Register )

> Upload forum rules

- No over 30 sec clips of copyrighted music. Cite properly and never more than necessary for the discussion.


- No copyrighted software without permission.


- Click here for complete Hydrogenaudio Terms of Service

50 Pages V  « < 12 13 14 15 16 > »   
Closed TopicStart new topic
lossyWAV Development, WAV bit reduction by 2BDecided
halb27
post Oct 18 2007, 21:24
Post #326





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



Thank you, Josef.
So with your test set the new clipping prevention scheme doesn't have a seriously bad influence on the bitrate.
I'll try and find some clipping-prone samples and test it too.

This post has been edited by halb27: Oct 18 2007, 21:24


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Nick.C
post Oct 18 2007, 22:00
Post #327


lossyWAV Developer


Group: Developer
Posts: 1791
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



I would like to remove the "-skew" parameter, as I believe that the new spreading function takes care of low frequencies by averaging fewer bins, i.e. giving more weight to the lowest FFT analysis results at low frequencies.

Please state any interest in retaining this parameter......

One thing to remember (and it's important) is that lossyWAV does not have a target bitrate in mind, only a quality level specified by the input parameters.

Also, due to the relatively small increase in total filesize on my sample set of the new -noclip (by bits_to_remove reduction) I would like feedback as to whether it should be on by default rather than have to be selected.

lossyWAV alpha v0.3.12 attached: Superseded.

In this version, the upper limits of the spreading function have been reduced to 12.4kHz and 15.8kHz respectively.

CODE
lossyWAV alpha v0.3.12 : WAV file bit depth reduction method by 2Bdecided.
Delphi implementation by Nick.C from a Matlab script, www.hydrogenaudio.org

Usage   : lossyWAV <input wav file> <options>

Example : lossyWAV musicfile.wav

Options:

-1, -2 or -3  quality level (1:overkill, 2:default, 3:compact)
-nts <n>      noise_threshold_shift=n (-15.0dB <= n <= 0.0dB, default -1.5dB)
              (reduces overall bits to remove, -1 bit = -6.0206dB)
-snr <n>      set minimum average signal to added noise ratio;
              (0.0dB <= n <= 48.0dB, default = 12.0dB)
-o <folder>   destination folder for the output file
-noclip       clipping prevention amplitude reduction; default=off
-force        forcibly over-write output file if it exists.

Advanced Options:

-skew <n>     skew fft analysis results by n dB
              (0.0db <= n <= 12.0db, default = 0.0dB) with a (sin-1) shaping in
              the frequency range 20Hz to 3.45kHz. (decrease low frequency bins
              to take into account higher SNR requirements at low frequencies)
-dither       dither output using triangular dither; default=off

System / Output options:

-quiet        significantly reduce screen output
-nowarn       suppress lossyWAV warnings
-detail       enable detailled output mode
-below        set process priority to below normal.
-low          set process priority to low.

Special thanks:

Dr. Jean Debord for the use of TPMAT036 uFFT & uTypes units for FFT analysis.
Halb27 @ www.hydrogenaudio.org for donation and maintenance of the wavIO unit.


Have fun now!

This post has been edited by Nick.C: Oct 20 2007, 19:58


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
halb27
post Oct 18 2007, 22:15
Post #328





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



I finished my listening test with my usual samples using v0.3.11 -spread 1.
Everything is fine.
This time it was furious with which I had a similar effect to the one I described last time for keys: sometimes I believed that the original is a subtle bit lower in tonality than the lossyWaved version. I arrived at 6/7 and finished at 7/10 so this can't be judged as being abxed. Anyway a bit strange, especially as it's a déja vu.

It would be great if someone could try furious and keys_1644ds.

Thank you, Nick, for the new version. Will test FLAC bitrate with lossyWav -noclip option and without as soon I have found a set of clipping-prone samples.

This post has been edited by halb27: Oct 18 2007, 22:17


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
2Bdecided
post Oct 19 2007, 10:54
Post #329


ReplayGain developer


Group: Developer
Posts: 5142
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



QUOTE (Nick.C @ Oct 18 2007, 20:00) *
Personally, I will probably use -3 as I too want to keep the bitrate down, but I am being lead by my more golden-eared colleagues with respect to level -2.
Apart from the fantastic dedication of halb27, I think your main problem Nick is that you're not getting input from anyone - Golden eared or otherwise. (Consider the number of people who were involved trying to make lame 3.90.3 transparent!)

I wish I had time to help with the skew vs variable-spreading choice from a theoretical standpoint. Without a fleet of golden ears you're stabbing in the dark.

If variable spreading was fundamentally correct, then extending it to higher frequencies wouldn't break things. It seems that it does. Never the less, given that it works at lower frequencies, that's good enough for me! I suspect that there are two possible approaches that could both work: variable-spreading, and fixed-spreading with frequency skew. Maybe the best is a combination of both. But again, if you have something that works, go for it. Just be aware that you don't have an army of golden Ears backing you up.

Cheers,
David.
Go to the top of the page
+Quote Post
Nick.C
post Oct 19 2007, 12:16
Post #330


lossyWAV Developer


Group: Developer
Posts: 1791
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (2Bdecided @ Oct 19 2007, 10:54) *
If variable spreading was fundamentally correct, then extending it to higher frequencies wouldn't break things. It seems that it does.
I take it from that you think that the 5 bin spreading between 12.4kHz and 15.8kHz has in some way reduced the quality of the output. The simple way round that would be to revert to 4 bin averaging in this frequency band as well.
QUOTE (2Bdecided @ Oct 19 2007, 10:54) *
Never the less, given that it works at lower frequencies, that's good enough for me! I suspect that there are two possible approaches that could both work: variable-spreading, and fixed-spreading with frequency skew. Maybe the best is a combination of both.
Taking on board what you said here, I have revised the skewing function and increased the upper skew limit to 48dB (too high, overkill, like the -snr maximum) and set a default -skew of 12dB (again like -snr, the user can actively switch it off by -skew 0). This coupled with the 2/3/4/5 bin weighting seems to give good reduction while maintaining higher bitrate on known problem samples. I am considering changing the default -nts values, but need feedback.

lossyWAV alpha v0.3.13 attached. Superseded.

clipping prevention default, use -clipping to disable;
12dB skew default, use -skew 0 to disable;
12dB average signal to added noise default, use -snr 0 to disable;

CODE
lossyWAV alpha v0.3.13 : WAV file bit depth reduction method by 2Bdecided.
Delphi implementation by Nick.C from a Matlab script, www.hydrogenaudio.org

Usage   : lossyWAV <input wav file> <options>

Example : lossyWAV musicfile.wav

Options:

-1, -2 or -3  quality level (1:overkill, 2:default, 3:compact)
-nts <n>      set noise_threshold_shift to n dB (-15dB<=n<=0dB, default=-1.5dB)
              (reduces overall bits to remove by 1 bit for every 6.0206dB)
-snr <n>      set minimum average signal to added noise ratio to n dB;
              (0dB <= n <= 48dB, default = 12dB)
-o <folder>   destination folder for the output file
-clipping     disable clipping prevention by iteration; default=off
-force        forcibly over-write output file if it exists.

Advanced Options:

-skew <n>     skew fft analysis results by n dB (0db<=n<=48db, default=12dB)
              in the frequency range 20Hz to 3.45kHz
-dither       dither output using triangular dither; default=off

System / Output options:

-quiet        significantly reduce screen output
-nowarn       suppress lossyWAV warnings
-detail       enable detailled output mode
-below        set process priority to below normal.
-low          set process priority to low.

Special thanks:

Dr. Jean Debord for the use of TPMAT036 uFFT & uTypes units for FFT analysis.
Halb27 @ www.hydrogenaudio.org for donation and maintenance of the wavIO unit.


This post has been edited by Nick.C: Oct 20 2007, 19:59


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
halb27
post Oct 19 2007, 14:17
Post #331





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (2Bdecided @ Oct 19 2007, 11:54) *
Apart from the fantastic dedication of halb27, I think your main problem Nick is that you're not getting input from anyone - Golden eared or otherwise. (Consider the number of people who were involved trying to make lame 3.90.3 transparent!)

So true, unfortunately.
Luckily we're not exactly in the same situation as the Lame devs.
Starting from your very first MATLAB version quality was already very high, and as long as variations are done in a defensive way lossyWav development isn't very dangerous qualitywise.
IMO taking it all in all the variants brought into lossyWav have a high probability of making progress towards ensuring quality even in difficult situations.
So IMO lossyWav can be used already for practical purposes.

Hopefully guruboolez will have time and test with the current version especially the problem he could abx.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Bourne
post Oct 19 2007, 16:39
Post #332





Group: Banned
Posts: 735
Joined: 19-March 06
Member No.: 28599



did you guys dropped "lossyFLAC" and adopted "lossyWAV" ?
Go to the top of the page
+Quote Post
Nick.C
post Oct 19 2007, 16:54
Post #333


lossyWAV Developer


Group: Developer
Posts: 1791
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (Bourne @ Oct 19 2007, 16:39) *
did you guys dropped "lossyFLAC" and adopted "lossyWAV" ?
Yes, simply because the pre-processing method is not limited to the FLAC codec. I believe that it works well with TAK and WavPack as well. Also, in the "old school" programming world, naming had to be done within 8 characters...... wink.gif

I'll release v0.3.14 tonight - I am dabbling in FPU assembly and have made one notable speedup already (changed Magnitude function, which calculates the magnitude of a complex number, to assembler). Having trouble picking double real values out of an array of complex numbers though.......

This post has been edited by Nick.C: Oct 19 2007, 16:58


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
Josef Pohm
post Oct 19 2007, 17:05
Post #334





Group: Members
Posts: 40
Joined: 2-April 06
Member No.: 29099



Comparison of 0.3.13 and 0.3.11 on my SetF.

Bits to remove table.
CODE
------- -------------------- -------------------- --------------------
|      |       0.3.13       |       0.3.11       |      13 vs 11      |
|       ------ ------ ------ ------ ------ ------ ------ ------ ------
|      |   1  |   2  |   3  |   1  |   2  |   3  |   1  |   2  |   3  |
------- ------ ------ ------ ------ ------ ------ ------ ------ ------
|  512 | 5,13 | 5,64 | 5,85 | 4,04 | 4,80 | 5,03 | 1,09 | 0,84 | 0,82 |
| 1024 | 4,88 | 5,25 | 5,40 | 3,77 | 4,42 | 4,58 | 1,11 | 0,83 | 0,82 |
| 2048 | 4,48 | 4,93 | 5,09 | 3,39 | 4,11 | 4,27 | 1,09 | 0,82 | 0,82 |
| 4096 | 4,11 | 4,55 | 4,70 | 3,05 | 3,75 | 3,91 | 1,06 | 0,80 | 0,79 |
------- ------ ------ ------ ------ ------ ------ ------ ------ ------

TAK 1.0.2e08 -p3m bitrate table (lossless 862kbps).
CODE
------- ----------------- ----------------- -----------------
|      |  TAK on 0.3.13  |  TAK on 0.3.11  |    13 vs 11     |
|       ----- ----- ----- ----- ----- ----- ----- ----- -----
|      |  1  |  2  |  3  |  1  |  2  |  3  |  1  |  2  |  3  |
------- ----- ----- ----- ----- ----- ----- ----- ----- -----
|  512 | 465 | 426 | 411 | 552 | 490 | 472 | -87 | -64 | -61 |
| 1024 | 470 | 441 | 430 | 557 | 504 | 491 | -87 | -63 | -61 |
| 2048 | 492 | 457 | 445 | 578 | 520 | 507 | -86 | -63 | -62 |
| 4096 | 517 | 482 | 471 | 602 | 545 | 532 | -85 | -63 | -61 |
------- ----- ----- ----- ----- ----- ----- ----- ----- -----
Go to the top of the page
+Quote Post
SebastianG
post Oct 19 2007, 17:06
Post #335





Group: Developer
Posts: 1318
Joined: 20-March 04
From: Göttingen (DE)
Member No.: 12875



QUOTE (Nick.C @ Oct 19 2007, 17:54) *
I'll release v0.3.14 tonight - I am dabbling in FPU assembly and have made one notable speedup already (changed Magnitude function, which calculates the magnitude of a complex number, to assembler). Having trouble picking double real values out of an array of complex numbers though.......


Regarding performance: How about using floats with single precision?

Cheers!
SG
Go to the top of the page
+Quote Post
2Bdecided
post Oct 19 2007, 17:42
Post #336


ReplayGain developer


Group: Developer
Posts: 5142
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



QUOTE (Nick.C @ Oct 19 2007, 12:16) *
QUOTE (2Bdecided @ Oct 19 2007, 10:54) *
If variable spreading was fundamentally correct, then extending it to higher frequencies wouldn't break things. It seems that it does.
I take it from that you think that the 5 bin spreading between 12.4kHz and 15.8kHz has in some way reduced the quality of the output.
No, not the current version - I thought halb27 had ABXed a previous version with wider spreading? Sorry if I was mistaken, or if that's the one he retracted.

Cheers,
David.
Go to the top of the page
+Quote Post
halb27
post Oct 19 2007, 17:56
Post #337





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (2Bdecided @ Oct 19 2007, 18:42) *
.... I thought halb27 had ABXed a previous version with wider spreading? Sorry if I was mistaken, or if that's the one he retracted.

In the end I could'nt abx a problem with any of the recent versions.

There is a small suspicion that someone else may really abx a problem with keys_1644ds and/or furious. I did beleive I can hear a subtle difference here, and my abx results were such that the listenenig results of other members are highly welcome.


@Nick: Looking at Josef's results: What makes 0.3.13 bring down the bitrate so significantly compared to 0.3.11?

This post has been edited by halb27: Oct 19 2007, 17:57


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
GeSomeone
post Oct 19 2007, 18:00
Post #338





Group: Members
Posts: 921
Joined: 22-October 01
From: the Netherlands
Member No.: 335



QUOTE (2Bdecided @ Oct 19 2007, 10:54) *
.. I think your main problem Nick is that you're not getting input from anyone ...
David.

It doesn't help that this "development" thread is in the Upload forum in stead of the FLAC forum where it was.
On the other hand, it is true that it no longer belongs in the lossless section wink.gif
Go to the top of the page
+Quote Post
Bourne
post Oct 19 2007, 18:24
Post #339





Group: Banned
Posts: 735
Joined: 19-March 06
Member No.: 28599



QUOTE (GeSomeone @ Oct 19 2007, 14:00) *
QUOTE (2Bdecided @ Oct 19 2007, 10:54) *

.. I think your main problem Nick is that you're not getting input from anyone ...
David.

It doesn't help that this "development" thread is in the Upload forum in stead of the FLAC forum where it was.
On the other hand, it is true that it no longer belongs in the lossless section wink.gif


if you guys could upload The "eig" sample with lossyWAV (provided with the lossless sample) I could try to ABX it. But I doubt I would since I did not with OGG at -q6. For what I have seen it would take a combination of a couple with golden years plus killer lossy codecs samples (gurubolez included..LOL).

This post has been edited by Bourne: Oct 19 2007, 18:24
Go to the top of the page
+Quote Post
halb27
post Oct 19 2007, 19:31
Post #340





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (Bourne @ Oct 19 2007, 19:24) *
if you guys could upload The "eig" sample ....

File space is restricted here.
I provide the sample for a limited time on my webspace:
zip version of eig.original.flac and eig.lossy.flac.

eig.lossy.flac is encoded with 0.3.13 (no special options).


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Nick.C
post Oct 19 2007, 19:33
Post #341


lossyWAV Developer


Group: Developer
Posts: 1791
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (GeSomeone @ Oct 19 2007, 18:00) *
QUOTE (2Bdecided @ Oct 19 2007, 10:54) *
.. I think your main problem Nick is that you're not getting input from anyone ...
David.
It doesn't help that this "development" thread is in the Upload forum in stead of the FLAC forum where it was.
On the other hand, it is true that it no longer belongs in the lossless section wink.gif
I can't upload in the FLAC forum.....


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
Nick.C
post Oct 19 2007, 21:02
Post #342


lossyWAV Developer


Group: Developer
Posts: 1791
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (halb27 @ Oct 19 2007, 17:56) *
@Nick: Looking at Josef's results: What makes 0.3.13 bring down the bitrate so significantly compared to 0.3.11?
There was a bug - there was no 5 bin averaging between 12.4kHz and 15.8kHz, the program was using 4 bin averaging.

@Sebastian: I tried that at an early stage but the output didn't match that of Mathcad, so I didn't pursue it. I may revert to single if I have no luck with 80x87 assembly language....


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
halb27
post Oct 19 2007, 21:27
Post #343





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



I searched my collection looking for clipping samples. Which turned out to be not easy.

Tracks which I know have strong distortions in them didn't have them due to clipping. And when I found clipping it usually was so isolated that it wasn't worth while trying. CDs with the typical loudness-war style kind of compression and clipping didn't have the clipping level very close to the 100% CD level.

In the end I found a CD wonderfully suited for worst-case testing: Francoise Hardy: Le temps des Souvenirs. Not the kind of music I expected to be clipping-prone. But it seems to be terribly remastered in this respect.
I took 16 tracks from this 2 CD album (everything from my productive collection plus everything I could perfectly re-rip from the 1st CD). I added 15 other tracks of various kind which made at least a slight impression that bitrate might go up with the iterative clipping prevention method.

I encoded these 31 tracks using lossyWav 0.3.13 with and without the -clipping option (no other option).

All the tracks: Average bitrate with -clipping: 419 kbps.
All the Tracks: Average bitrate without -clipping: 467 kbps.

A closer look:

Francoise Hardy tracks: Average bitrate with -clipping: 441 kbps.
Francoise Hardy tracks: Average bitrate without -clipping: 551 kbps.

Non-Francoise Hardy tracks: Average bitrate with -clipping: 401 kbps.
Non-Francoise Hardy tracks: Average bitrate without -clipping: 402 kbps.

So with tracks loundness-war style and clipping at or very close to the peak level sure this clipping prevention scheme increases bitrate significantly.
On the other hand at least judging from my collection (and I looked at quite a lot of CDs published in recent years) it doesn't happen very often that bitrate bloat requirements are fulfilled.

In order to take everything into account a more elaborated clipping prevention method could be like this:
Encode with the iterative clipping prevention strategy. When doing so, compute the average bits removed also for the variant of pretending the clipping prevention strategy is not used (can easily be done in parallel - no extra encoding necessary). If in the end it turns out the percentage of the difference between the two strategies is too high, reencoding can occur with a scale factor for preventing clipping.
From all we know so far reencoding is rarely necessary, and in these strong clipping cases it's easy to accept the theoretical quality impact of scaling.

The threshold for reencoding can vary with quality level, for instance like this:
-1: no reencoding with scaling no matter what bits to remove difference
-2: reencoding with scaling in case bits to remove difference is greater than 10%.
-3: reencoding with scaling in case bits to remove difference is greater than 5%.

This post has been edited by halb27: Oct 20 2007, 21:20


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
halb27
post Oct 19 2007, 22:19
Post #344





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



I listened to my usual sample set with v0.3.13 (no option).
Everything is fine.
Amazing for this rather low bitrate on average with usual samples.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Nick.C
post Oct 19 2007, 22:31
Post #345


lossyWAV Developer


Group: Developer
Posts: 1791
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (halb27 @ Oct 19 2007, 22:19) *
I listened to my usual sample set with v0.3.13 (no option).
Everything is fine.
Amazing for this rather low bitrate on average with usual samples.
smile.gif I'm *really* glad that the new spreading function / skew combination is working [good shout, David!]! Also, keeping the bitrate down is nearly as important.

Is there any appetite for correction files? I have been toying with the idea of this option but it's not worth doing if there is no "market".

lossyWAV alpha v0.3.14 attached: - superseded.

No parameter changes, just faster.

This post has been edited by Nick.C: Oct 23 2007, 20:37


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
Nick.C
post Oct 21 2007, 23:21
Post #346


lossyWAV Developer


Group: Developer
Posts: 1791
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



lossyWAV alpha v0.3.15 attached. Superseded.

Code speeded up again.

Changes made to quality level -3 to make it slightly more aggressive : codec_block_size changed from 1024 samples to 512; -nts default changed from -1 to -0.5.

I'm considering making quality level -1 more conservative by setting the codec_block_size to 2048 samples. Input required please.

CODE
lossyWAV alpha v0.3.15 : WAV file bit depth reduction method by 2Bdecided.
Delphi implementation by Nick.C from a Matlab script, www.hydrogenaudio.org

Usage   : lossyWAV <input wav file> <options>

Example : lossyWAV musicfile.wav

Options:

-1, -2 or -3  quality level (1:overkill, 2:default, 3:compact)
-nts <n>      set noise_threshold_shift to n dB (-15dB<=n<=0dB, default=-1.5dB)
              (reduces overall bits to remove by 1 bit for every 6.0206dB)
-snr <n>      set minimum average signal to added noise ratio to n dB;
              (0dB<=n<=48dB, default=12dB)
-skew <n>     skew fft analysis results by n dB (0db<=n<=48db, default=12dB)
              in the frequency range 20Hz to 3.45kHz
-o <folder>   destination folder for the output file
-clipping     disable clipping prevention by iteration; default=off
-force        forcibly over-write output file if it exists; default=off

Advanced / System Options:

-dither       dither output using triangular dither; default=off

-quiet        significantly reduce screen output
-nowarn       suppress lossyWAV warnings
-detail       enable detailled output mode

-below        set process priority to below normal.
-low          set process priority to low.

Special thanks:

Dr. Jean Debord for the use of TPMAT036 uFFT & uTypes units for FFT analysis.
Halb27 @ www.hydrogenaudio.org for donation and maintenance of the wavIO unit.


This post has been edited by Nick.C: Nov 7 2007, 22:44


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
halb27
post Oct 22 2007, 06:29
Post #347





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (Nick.C @ Oct 22 2007, 00:21) *
...I'm considering making quality level -1 more conservative by setting the codec_block_size to 2048 samples. Input required please. ...

I welcome the approach of putting more details into -1, -2, -3, as well as a more pronounced differentiation security-/and bitrate wise for -1 and -3, with -2 being the standard as ever with a good but not exaggerated security margin.

But what is the advantage of a blocksize of 2048 for -1?

Indepent of the block size question for -1 I personally would like to see a new approach with spreading_length=1 for low frequencies and short ffts cause in this case the current approach averages over more than 1 critical band.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Nick.C
post Oct 22 2007, 08:14
Post #348


lossyWAV Developer


Group: Developer
Posts: 1791
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (halb27 @ Oct 22 2007, 06:29) *
QUOTE (Nick.C @ Oct 22 2007, 00:21) *
...I'm considering making quality level -1 more conservative by setting the codec_block_size to 2048 samples. Input required please. ...
I welcome the approach of putting more details into -1, -2, -3, as well as a more pronounced differentiation security-/and bitrate wise for -1 and -3, with -2 being the standard as ever with a good but not exaggerated security margin.

But what is the advantage of a blocksize of 2048 for -1?

Indepent of the block size question for -1 I personally would like to see a new approach with spreading_length=1 for low frequencies and short ffts cause in this case the current approach averages over more than 1 critical band.
A codec_block_size of 2048 will reduce bits to remove by effectively taking the lower of two bits_to_remove values for consecutive small blocks and applying that to the large block. It's a possibility, but more conservatism might better be achieved by increasing the default "-snr" value for -1 from 12dB (the same for all quality levels at the moment) to a larger value.

At present for my 52 sample set WAV: 121.53MB; FLAC: 68.20MB, 791.9kbps; -1: 42.97MB 499.0kbps(106.1% -2); -2: 40.49MB, 470.2kbps; -3: 37.68MB, 437.5kbps (93.1% -2). A quick test of "-1 -snr 24" gave 44.67MB, 518.7kbps (110.3% -2).

I will have a look at spreading_function_length with respect to Critical Bandwidth and post.

[edit] See attached Excel sheet. I will have a think as to how best to implement this, without reverting to my abortive previous attempt at Bark averaging. [/edit]

This post has been edited by Nick.C: Oct 22 2007, 09:16


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post
halb27
post Oct 22 2007, 12:36
Post #349





Group: Members
Posts: 2435
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (Nick.C @ Oct 22 2007, 09:14) *
A codec_block_size of 2048 will reduce bits to remove by effectively taking the lower of two bits_to_remove values for consecutive small blocks and applying that to the large block. It's a possibility, but more conservatism might better be achieved by increasing the default "-snr" value for -1 from 12dB (the same for all quality levels at the moment) to a larger value.

I understand well that you want to be conservative qualitywise with -1, and a blocksize of 2048 certainly will reduce bits to remove, but from my naive understanding I cannot see a promising impact of a 2048 sized block on quality. The -snr approach or an increased value of -nts or -skew are more promising to me.

My personal feelings however go strongly in the direction that for FFT lengths <= 256 the spreading length is two long in case the width of critical bands are worth taking into account.
Sure there must be compromise, and IMO the current results are very good. But in favor of conservatism for -1 a shorter spreading length at least for a FFT length of 64 and low frequency is welcome IMO (spreading_length=1 in this case), and in case the influence on bits removed remains acceptable even for a FFT length of 128 and maybe 256 spreading length should be tried to get lower than they are now, and if possible not only for the low frequency end.

This post has been edited by halb27: Oct 22 2007, 12:40


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Nick.C
post Oct 22 2007, 12:59
Post #350


lossyWAV Developer


Group: Developer
Posts: 1791
Joined: 11-April 07
From: Wherever here is
Member No.: 42400



QUOTE (halb27 @ Oct 22 2007, 12:36) *
QUOTE (Nick.C @ Oct 22 2007, 09:14) *
A codec_block_size of 2048 will reduce bits to remove by effectively taking the lower of two bits_to_remove values for consecutive small blocks and applying that to the large block. It's a possibility, but more conservatism might better be achieved by increasing the default "-snr" value for -1 from 12dB (the same for all quality levels at the moment) to a larger value.
I understand well that you want to be conservative qualitywise with -1, and a blocksize of 2048 certainly will reduce bits to remove, but from my naive understanding I cannot see a promising impact of a 2048 sized block on quality. The -snr approach or an increased value of -nts or -skew are more promising to me.
I agree, a -snr / -skew combination will probably be a better solution. I am running a matrix calculation of -snr 0 to 30 step 3, -skew 0 to 30 step 3 to see what happens with bitrate for my sample set.
QUOTE (halb27 @ Oct 22 2007, 12:36) *
My personal feelings however go strongly in the direction that for FFT lengths <= 256 the spreading length is two long in case the width of critical bands are worth taking into account.
Sure there must be compromise, and IMO the current results are very good. But in favor of conservatism for -1 a shorter spreading length at least for a FFT length of 64 and low frequency is welcome IMO (spreading_length=1 in this case), and in case the influence on bits removed remains acceptable even for a FFT length of 128 and maybe 256 spreading length should be tried to get lower than they are now, and if possible not only for the low frequency end.
I am currently looking at what impact a spreading_function_length of 1 would have and how to implement it. It could be as simple as if FFT_length<256 then spreading_function_length=1. if 256 or 512 then 1,2,3,4. if 1024 or above then 2,3,4,5.


--------------------
lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps
Go to the top of the page
+Quote Post

50 Pages V  « < 12 13 14 15 16 > » 
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd September 2014 - 22:35