Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: lossyWAV 1.2.0 Development Thread (Read 311901 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lossyWAV 1.2.0 Development Thread

Reply #425 –
Isn't there another syntax in Linux to deal with spaces? If I remember correctly you put a backslash before each space, like Program\ Files.

lossyWAV 1.2.0 Development Thread

Reply #426 –
Quote from: PowerPaul86 on
Unfortunately i get the same error messages as before. 


The message should be self explanatory:  lossyWav does not support lossless (or lossy) formats. Just plain PCM ( inside RIFFWave ). 

The syntax you have put in foobar2000 does the lossywav processing of the wave (that foobar2000 has previously decoded from the original flac), and pipes that PCM data to flac for encoding.

But i guess that being a linux user, you may already know that

lossyWAV 1.2.0 Development Thread

Reply #427 –
Inserting
Code: [Select]
FLAC -d <filename> --stdout --silent
(followed by a pipe symbol) before the rest of the command line would allow you to test outside of foobar2000.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #428 –
@Hancoque
Yes, i know that you need to escape the space character in a linux command, but using it under wine?
You would end up with something like that:

Quote
/d /c C:\"Program\ Files"\bin\lossywav - --standard --silent --stdout|C:\"Program\ Files"\bin\flac - -b 512 -5 -f -o%d


Which doesn't work at all. Sure you could try different methods to get that path right, but to me moving the exe files to another easier to address path seems to be the simplest/best option.

@[JAZ]

I realized, after looking at the RIFF article on wikipedia, that i needed a WAV file instead of a FLAC file.
But i only wanted to illustrate with that picture what i had in mind - a simple conversion.

lossyWAV 1.2.0 Development Thread

Reply #429 –
lossyWAV beta 1.1.4a attached to post #1 in this thread.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #430 –
Thank you, Nick.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #431 –
Quote from: botface on
Quote from: Nick.C on
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"

Are these settings useful to achieve lower bitrates with acceptable quality?

Since the nature of lossyWAV is that it improves compression, it would make sense to spend more encoding time on lower quality files than on higher quality files. Since they achieve the lowest bitrate. The settings could even be part of the low-quality presets

lossyWAV 1.2.0 Development Thread

Reply #432 –
I'm not the best person to answer this but, yes, the --sortspread parameter does improve quality a bit (note that now it's been implemented it is a simple on/off switch not a 0-7 range anymore). However, using it results in an increase in the bitrate compared with not using it (at the same -q level). The debate over its usefulness is that simply using a higher q level (like -q 2.8 instead of -q 2.5) achieves the same thing : IE better quality at a higher bitrate. Having said that you may find that using say, -2.5 --sortspread gives a lower bitrate and the same perceptual quality as -q 2.8 with the type of music you listen to. I think it's basically a 'try it and see if it works for you' situation

lossyWAV 1.2.0 Development Thread

Reply #433 –
lossyWAV beta 1.1.4b attached to post #1 in this thread.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #434 –
Why not use FFTW for FFT analysis?

lossyWAV 1.2.0 Development Thread

Reply #435 –
If I could find a pre-compiled Delphi compatible library and an interface then I would. However, I have enjoyed optimising the FFT routines in Delphi / IA-32/x87.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #436 –
Quote from: Nick.C on
If I could find a pre-compiled Delphi compatible library and an interface then I would. However, I have enjoyed optimising the FFT routines in Delphi / IA-32/x87.

Might this be useful?

I found that here (scroll down to "FFTW 3.x and Borland Delphi", there is also a link to a Pascal interface file there for calling FFTW from Borland Delphi, and also a link to the compiled library), which was the first result of this Google search.

I hope that helps.

lossyWAV 1.2.0 Development Thread

Reply #437 –
Thanks for that - I have to admit that I didn't look too hard for it. I have downloaded the DLL and an interface unit and have begun the integration process. It is currently working, however not very fast, so I think that I have some learning to do regarding using FFTW.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #438 –
Quote from: Nick.C on
Thanks for that - I have to admit that I didn't look too hard for it. I have downloaded the DLL and an interface unit and have begun the integration process. It is currently working, however not very fast, so I think that I have some learning to do regarding using FFTW.

No problem, I'm really glad I managed to help! I think lossyWAV is awesome and I'm happy to help its development in any way I can, even if it's just by providing a link.

And I believe using FFTW should help increase lossyWAV's sound quality, because it's one of the most precise FFT libraries, if not the most precise (in those graphs, lower is better because they measured the calculation error. Other accuracy benchmark results can be found here).

lossyWAV 1.2.0 Development Thread

Reply #439 –
Right - thanks to the gentle nudge from doccolinni - I have implemented a -F or --fftw parameter in lossyWAV. This enables the exclusive use of libfftw3-3.dll for FFT calculations. The slow running I was experiencing initially was as a result of my testing (initially) on my 55 problem sample set (12m28s in total). Processing short files vastly overemphasises the effect of the time used in the fftw planning phase compared to faster FFT calculations. Using a single album (39m41s duration) as a test piece and --zero as the only other parameter, the assembler version processes in 27.7 seconds and in 24.7 seconds with --fftw enabled, a saving of approximately 11%. At --standard the difference is more pronounced: 45.0 seconds vs 36.3 seconds or a 19% saving.

This is certainly worthwhile (and the integration is complete) so I will be releasing beta 1.1.4c as soon as I can determine exactly what text to add where to credit fftw.org and the creators of the Delphi fftw interface unit. The libfftw3-3.dll file would also require to be distributed (or downloaded) to allow the --fftw parameter to be used.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #440 –
Oh, and the output of my assembler version and the fftw output are identical....

[edit] Problem with short files fixed (at least on my Intel C2D) by changing the flags used when setting up the plan for each FFT length. 55 problem sample set now processes faster using --fftw than default. I am well pleased and will endeavour to release ASAP. [/edit]
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #441 –
Quote from: Nick.C on
Oh, and the output of my assembler version and the fftw output are identical....

Well that's interesting, I thought it might have different results... But anyway,...

Quote from: Nick.C on
[edit] Problem with short files fixed (at least on my Intel C2D) by changing the flags used when setting up the plan for each FFT length. 55 problem sample set now processes faster using --fftw than default. I am well pleased and will endeavour to release ASAP. [/edit]

...yay!  I'm glad that the initial slow running was not a serious problem and that it works faster now! Can't wait till you release the next version.

lossyWAV 1.2.0 Development Thread

Reply #442 –
Well, since I'm here I might as well ask a question and make another proposition I've had in mind:

Question(s): Do FLAC's quality commands, like -8 for example, set a specific value for the block size? If they do, will -b 512 override them?

Proposition: This one is regarding the dithering. As the Wikipedia article plainly puts it:
Quote
Dither is an intentionally applied form of noise, used to randomize quantization error, thereby preventing large-scale patterns such as "banding" (stepwise rendering of smooth gradations in brightness or hue) in images, or noise at discrete frequencies in an audio recording, that are more objectionable than uncorrelated noise.

Of course, I'm not presuming that you don't know what "dither" means, I was just making sure that you're aware that I know what it means and that what I'm about to propose is actually based on understanding the concept of dithering. Since the noise added by lossyWAV is already transparent at higher quality settings, perhaps dithering should take place only with --zero, --nasty and --awful to reduce the "unpleasantness" of the added noise? It's probably best to just forget about dithering for the moment and implement it in future development, or maybe implement a testing command --dither or something like that.

Just to talk a bit more about dithering itself, to make sure that I've got the right idea in my mind:

So let's say that we've got an audio file with bit-depth of, for the sake of simplicity, 4 (yes, that's ridiculous, but I just want to keep it simple, to check whether my idea of dithering is correct). So the possible values for audio peaks in that file range from 0000 to 1111. Now let's say that one peak has a value of 1001. And then BAM, lossyWAV comes in and decides that two bits are enough for the chunk wherein lies that very audio peak (that's even more ridiculous, but bear with me). So now the only possible values in that chunk are 0000, 0100, 1000 and 1100. Without dithering, the value of our peak would simply be rounded to 1000. But with dithering, lossyWAV would first calculate how far the value of that peak is from the two of these new possible values in-between which it lies, which are 1000 and 1100. The (absolute) difference between 1001 and 1000 is 1, and between 1001 and 1100 it's 3 (11 in binary). And now, lossyWAV would randomly assign one of these two values to the peak in question, so that the possibility of it being 1000 or 1100 depends on the ratio of these two (absolute) differences. So since the initial value of the peak is three times closer to 1000 than it is to 1100, the possibility of the new value being 1000 has to be three times greater than the possibility of it being 1100. So it would be 75% chance that the new value will be 1000 and 25% chance that the new value will be 1100.

Is that the correct understanding of dithering?

lossyWAV 1.2.0 Development Thread

Reply #443 –
Dither has previously been included but was removed after consultation with David.

Noise shaping is included using SebastianG's 44.1kHz and 48kHz coefficients - increasing the proportion of noise shaping may solve what you're hearing. The default shaping is quality/10, i.e. 25% at --portable, 50% at --standard, etc. The proportion shifts the noise shaping from pure white noise (--shaping 0) to pure noise shaped noise (--shaping 1). The downside of noise shaping is that its output is difficult for FLAC to predict, so the resultant FLAC bitrate increases quite dramatically.

One final point, FLAC has no quality commands - it has compression settings. FLAC is lossless after all....
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #444 –
Quote from: Nick.C on
One final point, FLAC has no quality commands - it has compression settings. FLAC is lossless after all....

Oh, yes, that's, of course, what I actually meant.  So will -b 512 override any block size settings that might be defined by them?

I hope my understanding of dithering is correct (can you verify that it is, I've explained my idea in my previous post?), but I'm not really familiar with the process of noise shaping... I'll read through the Wikipedia article on it though and try to figure it out.

lossyWAV 1.2.0 Development Thread

Reply #445 –
Yes, the -b 512 parameter will set the FLAC block size to 512 samples, over-riding any internal presets.

The bits that are being removed have a 50% chance of rounding up, 50% down - exactly the same as dither in the range -0.5 to +0.5.

For 4 bits (signed) we would have a range 1000 (-8) to 0111 (+7). lossyWAV does its rounding in floating point so there is no chance of rollover from +7 to -8. +7 would indeed round to +8 in the floating point domain if two bits were to be removed but lossyWAV has a check in place which limits the maximum rounded value to (2^(bits_per_sample-1) shr (bits_to_remove)) shl (bits_to_remove), i.e. 4 bits per sample, 2 bits to remove would yield a maximum value of 0100. I agree 4 bits per sample with 2 bits to remove is an extreme example. lossyWAV has a defined static_minimum_bits_to_keep which is equal to 5 and calculates a dynamic minimum_bits_to_keep which relates to the RMS value of the input samples (for each FFT analysis).
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #446 –
Quote from: Nick.C on
The bits that are being removed have a 50% chance of rounding up, 50% down - exactly the same as dither in the range -0.5 to +0.5.

Oh. I thought it depends on how far from each end the particular peak is. :-/

Thanks for the explanation(s).

So how is the development of the next beta coming along?
 

lossyWAV 1.2.0 Development Thread

Reply #447 –
I would expect to sort out the required text for the next beta by this weekend.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #449 –
lossyWAV beta 1.1.4c attached to post #1 in this thread.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)