lossyWAV 1.2.0 Development Thread, Added noise WAV bitdepth reduction method Options

[halb27]

Thanks for testing.
A stronger noise shaping value concentrates the noise more in the 13+ kHz region.
With very low quality settings this may be counterproductive.
So if you have the time I'd welcome if you could give -s 0.3 or -s 0.35 a chance for -q 2. This would be the very first listening test to comfirm or improve on the optimum value for noise shaping strength (at -q 2). So far just a plausible value is chosen as a function of the -q level (q/10), but there has never been a real justification. It would be great if you could do that, especially as it is about the sensitive --portable setting.

This post has been edited by halb27: Apr 19 2009, 13:06

[sauvage78]

I found a new sample that I can ABX at -q 1.5, it is not as easy as Abfahrt Hinwil but it is less tiring than Therion, it produces some very light cracklings at regular interval on a repeted specific instant of the melody. At -q 1.5 it is hard to ABX when you haven't catched it, listen to -q 0 first to have an idea then increase the bitrate. Once trained it's easy/medium to ABX. The sample comes from the lame sample archive, I have shortened it. I will upload my version later.

CODE

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/20 08:04:29

File A: C:\02- Fool's Garden (Artefact Only) Lossless.flac
File B: C:\02- Fool's Garden (Artefact Only) V1.1.3j -q 1.5.lossy.flac

08:04:29 : Test started.
08:04:56 : 01/01  50.0%
08:05:18 : 02/02  25.0%
08:05:49 : 03/03  12.5%
08:06:01 : 03/04  31.3%
08:06:15 : 04/05  18.8%
08:06:39 : 05/06  10.9%
08:06:54 : 06/07  6.3%
08:07:16 : 07/08  3.5%
08:07:32 : 08/09  2.0%
08:07:47 : 09/10  1.1%
08:08:03 : 10/11  0.6%
08:08:28 : 11/12  0.3%
08:08:32 : Test finished.

----------
Total: 11/12 (0.3%)

Edit:
The edited sample is available here
Fool's Garden

On the short version (artefact only) you can split the 8 movements like this 1-2/1-2/1-2/-1-2, there is always a light crackling on 2. So it's very located.

This post has been edited by sauvage78: Apr 20 2009, 13:47

[halb27]

I tried eig (aka Abfahrt Hinwil) and Fool's Garden trying to find out audible differences for -q 1.5 for the default -s 0.15 in comparison with slightly increased -s values. However I can't hear the problem even with plain -q 1.5. Looks like I'm pretty bad at ABXing, at least right now.

However I found something strange. When encoding with foobar using the usual piping for foobar | lossyWAV | FLAC bitrate a lot higher for eig than when I used lossyWAV and FLAC directly from the command line.
So I compared these two procedures on my regular music test set for --portable, and bitrate came down from 385 kbps (piped procedure) to 381 kbps (commandline procedure).
Looking at the files bitrate decrease was higher for smaller files, which explains the very remarkable difference on problem sample snippets.

Well 381 kbps isn't a lot lower than 385 kbps, but it's not negligible to me. So I'm gonna use a good old bat file for the lossyFLAC encoding from within foobar which is the automatic equivalent of doing things on the command line.

I wonder what extra information is piped which makes it's way into the output .lossy.flac file.

This post has been edited by halb27: Apr 21 2009, 21:52

[Nick.C]

It's FLAC in combination with foobar2000. For an unlimited file length (the way that Foobar pipes), passed through lossyWAV, into FLAC, there is a 64kB padding block added to the resulting FLAC file.

[halb27]

Thank you, Nick.

[halb27]

Now that I'm using a .bat file again for encoding from within foobar I'd like to tag the output as being preprocessed by lossyWAV, something we've done before using --keep-foreign-metadata. But no matter wheather I do it this way or having FLAC tag the file by -T Comment="LossyWAV 1.1.3e --portable" I don't get the tag in the output file. Guess it's foobar's final tagging which deletes the comment tag. I also tried with a specific preprocessor tag but it's the same.

Any ideas?

This post has been edited by halb27: Apr 27 2009, 19:09

[Nick.C]

In foobar's output window (if you have selected it to popup on completion of processing) Ctrl-A to select all of the files and Alt-Enter to open the properties window - there, add a tag named LOSSYWAV with a value "1.1.3e --portable".

Not elegant, but if you are doing a large transcode quite quick per file.

[Nick.C]

I've been working on the FFT part of the program and have implemented a Radix-4 FFT algorithm. This improves processing time for the pure Delphi version but not at all for the version with IA-32 / x87 speedups (about a 10% reduction in throughput - I reckon the assembler Radix-2 FFT algorithm is quite tight and the Radix-4 version will take quite some optimisation....).

Has there been any clear decision regarding the --sortspread parameter? My interpretation thus far is that it has met with little enthusiasm. Not a problem, I would just like to know if it should be culled from v1.2.0.

[sauvage78]

My personal opinion on --sortspread/--underlap/--analyses is that all this parameters does increase the quality within the same setting but all have drawback in speed/bitrate that make them useless because if you compare at same bitrate the old scale is always better. If you can increase speed/decrease bitrate while keeping the same quality improvement some of these parameter might become usefull (specially --sortspread). If you cannot, in there actual state, none of the parameters I tested are usefull. I was optimistic at the beginning but now that all have been tested, I was asking myself why you weren't releasing lossywav 1.2 ? (... and also why you were still displaying -a 5 in your signature )

This post has been edited by sauvage78: Apr 27 2009, 21:02

[Nick.C]

Using --analyses 5 does indeed slow down processing rate (significantly) and increase bitrate (marginally) but that is the setting that I used for the last full transcode I did.

I still think that --underlap / --analyses and --sortspread have merit, I just don't know exactly which "level" of each is appropriate.

On speed - if the desired result is a reasonable bitrate / quality combination then processing rate (within reason) doesn't matter - just leave the computer merrily transcoding to its hearts content and wait until it is finished.

[halb27]

In foobar's output window ...

Thank you, Nick, for the hint. Really not very elegant, as you say. What a pity. I'll keep doing it in the Explorer by means of a context menu entry for folders.

As for underlap etc. my personal feeling is like what sauvage78 said. --portable is fine as is, and there's not a big chance for a lower -q setting and an added feature out of these to get at a remarkably lower bitrate while maintaining quality. But there's no need to put away with these features either. I know you would like them to prove useful so why not keep them? LossyWAV has a lot of advanced options anyway, but thanks to the main quality options --portable, --standard, etc. everybody who doesn't like them can ignore them.

This post has been edited by halb27: Apr 27 2009, 22:45

[botface]

Has there been any clear decision regarding the --sortspread parameter? My interpretation thus far is that it has met with little enthusiasm. Not a problem, I would just like to know if it should be culled from v1.2.0.

My view is that they're all worth keeping, just because they may be useful in some circumstances - Sauvage78 found some improvements on his problem samples. Perhaps they may help on others too (if any are ever found). There's always the option of simply using a higher q level if you want to keep things simple. I wouldn't worry about extra encode times. You only encode once. Sorry I can't be of any help suggesting suitable "levels"

[2Bdecided]

@Nick,

Can you see "inside" the processing to see what was happening here...

http://www.hydrogenaudio.org/forums/index....st&p=628046

...i.e. why that caused an easy to ABX difference?

Cheers,
David.

[PowerPaul86]

Hi there,

i wanted to ask if there is still any special wine parameter that you have to add when trying to use lossywav with an higher version than 1.0?

Or did the wine support stopped after that version?

[Nick.C]

The issues with WINE are undetermined. WINE support up to v1.0.0b was a fortuitous happening, not a conscious decision to support it. I can only hazard a guess that it may have something to do with the piped input / output which was introduced at v1.1.0. Source is available should anyone wish to track down the cause of the recent incompatibility.

[edit] However, thinking about it, it may be possible to remove the piping altogether and revert to simple screen output rather than sending all text output to the console. I will endeavour to produce a version which does this, although it may not be the cause of the issue and I don't have any platform upon which to test WINE compatibility. [/edit]

This post has been edited by Nick.C: Apr 29 2009, 21:04

[Nick.C]

lossyWAV beta 1.1.3k attached to post #1 in this thread. This is attempt #1 to regain WINE compatibility.

This post has been edited by Nick.C: Apr 30 2009, 08:54

[shadowking]

lossyWAV beta 1.1.3k attached to post #1 in this thread. This is attempt #1 to regain WINE compatibility.

Thanks. It works again. Wine stable 1.01

[Nick.C]

Fantastic, thanks very much for the quick confirmation - now, is there any appetite for a "fixed" v1.1.0b to be released prior to the forthcoming (but as yet date not fixed) release of v1.2.0?

[edit] Should have said earlier - piping is still very much integrated, I found a likely culprit problem which didn't require me to remove piped I/O. [/edit]

This post has been edited by Nick.C: Apr 30 2009, 14:32

[shadowking]

Fantastic, thanks very much for the quick confirmation - now, is there any appetite for a "fixed" v1.1.0b to be released prior to the forthcoming (but as yet date not fixed) release of v1.2.0?

Yes please.

[Nick.C]

lossyWAV 1.1.0c attached to post #1 of the lossyWAV 1.1.0 release thread.

[PowerPaul86]

wow thank you very much for that fast response and solution!

[Nick.C]

No problem - to be honest, it's something that has been annoying me for a while now. I realised today that it had to be to do with the piped output in some way - it turned out to be the way that I was ensuring that text output went to the console. I used an old method whereby a file with the name "con" is opened and all text destined for the screen is written to that "text file". I googled a reference today that informed me that stderr also goes to the console and is not redirected when stdout is. This is available in Delphi as the "ErrOutput" file handle - so I used that and deleted the previous method.

I'm very glad that it proved to be the issue as I did not want to remove piped I/O due to the significant speed gains achievable when using it.

[PowerPaul86]

I still got some problems converting flac files to lossyWAV

Maybe you got a clue what i am doing wrong :/

I can convert to flac files without any problems and i can execute lossywav.exe with wine as you can see in the following screenshot:



But when i start converting a file it gives me the following two error reports:



Here are my settings:




Any ideas?


Thanks in advance!

[Nick.C]

Try changing C:\"Program Files"\bin\lossywav.exe to "C:\Program Files\bin\lossywav.exe" - that may help (similar with the FLAC part of the command line).

[PowerPaul86]

Unfortunately i get the same error messages as before.

Could i test the lossywav conversion without the foobar player so i can exclude foobar as the source of the I/O error?

Something like that:




Thanks for your help!
I know it's not intended to run under linux/wine.


-----------------------------------------------------------------------------------------------------------------------------

Ha! Success!

It seems wine doesn't like it, when the path to the lossywav or flac includes a space character.

I moved the executables to the root path and changed the foobar encoder parameters to:

/d /c "C:\lossywav.exe" - --standard --silent --stdout | "C:\flac.exe" - -b 512 -5 -f -o %d

And it worked!

I should have tried that earlier!

This post has been edited by PowerPaul86: May 3 2009, 14:42