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.4.2 Development (was 1.5.0) (Read 110821 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #75 –
Quote from: alter4 on
If I use 1,4,1m with command line  '--quality high' Is that option still the best recommended setting for this level of quality or I can improve the quality by adding force hybrid shaping to the command line? 
Nobody answered so I made comparison of 2 sines signal with " --quality standard" vs  "--quality standard -s h" settings.
The result is below (hudrid, original and pure standard)
http://imgur.com/a/O5eX9
Of course the noise in all cases is inaudible but pure standard looks better. I stick to pure standard settings.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #76 –
I had some trouble using lossyWav lately, turns out 1.4.1m has expired.
In theory, there is no difference between theory and practice. In practice there is.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #77 –
Quote from: GeSomeone on
I had some trouble using lossyWav lately, turns out 1.4.1m has expired.

Nick has been exactly on time releasing a new beta everytime. Wonder what's up.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #78 –
lossyWAV beta 1.4.1n attached to post #1 in this thread.

(apologies for the late arrival)
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)

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #79 –
Hi,

I've found the idea of this wave processor to be quite interesting, and yesterday I completed porting the code to probably most modern POSIX systems (i.e., Linux, *BSD, MacOS X, AIX, etc.) I've tested it on Linux and FreeBSD and things seem to work (I haven't tried all the options, though, so there may be bugs.) It's also possible I accidentally broke the Windows version.

This is the summary of changes:
* Replaced all native Windows calls with their POSIX counterparts (used pre-processor blocks to write OS-specific code)
   - Also made some minor portability changes, like calling main int main(int, char**) instead of int main(uint32_t, char**)
   - Note: MinGW and/or Cygwin support may (or may not) be broken, because the Win32 API is preferred over POSIX. I'm not sure how these subsystems like non-POSIX code.
* Added myself as an author to this relase (to comply with GPL requirements)
   - I've called this release of mine 1.4.2 (we can talk about versioning so that people don't get confused)
   - Feel free to implement my changes into your next release (I can provide a diff file), then we don't have two separate branches
* Converted the files to UTF-8 for better portability
* Fixed some things apparently were bugs
   - For example, some attributes in nSGNS.h (lines 66-68) didn't receive their alignment attribute.
   - Also, in nWav.cpp, lines 1265 and 1300, I fixed a comparison from if (!foo == bar) to if (foo != bar). The original form gets evaluated as if ((!foo) == bar), and since !foo is always 0 or 1 and bar is probably neither, the code never gets executed. The exact code was "if (!thisRIFF.File.Read(thisRIFF, (char*) thisMapRecord->DATA, thisChunkSize) == thisChunkSize)"

The code is available on GitHub[1] and attached to this post. I'm thinking about rewriting the entire utility in C, designing it for portability from the beginning and incorporating OpenCL or CUDA support for FFT, bit removal and noise shaping. It should certainly speed it up. Should I begin this project, I'll make sure to share it on a new thread.

[1] https://github.com/corrideat/lossywav

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #80 –
Quote from: corrideat on
Hi,

I've found the idea of this wave processor to be quite interesting, and yesterday I completed porting the code to probably most modern POSIX systems (i.e., Linux, *BSD, MacOS X, AIX, etc.) I've tested it on Linux and FreeBSD and things seem to work (I haven't tried all the options, though, so there may be bugs.) It's also possible I accidentally broke the Windows version.


https://hydrogenaud.io/index.php/topic,107774.msg884548.html

Quote
I'm thinking about rewriting the entire utility in C, designing it for portability from the beginning and incorporating OpenCL or CUDA support for FFT, bit removal and noise shaping. It should certainly speed it up.

https://hydrogenaud.io/index.php/topic,107081.msg897190.html#msg897190

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #82 –
I cannot edit my former post, but I think I concluded that there is no official source repository. Perhaps people spring up those repos based on the source at https://hydrogenaud.io/index.php/topic,107081.msg

Nick,

If so, would you consider hosting the source on GitHub or somewhere. I am not saying it is top priority, but getting everyone who wishes to fix the Linux compatibility (or other issues) to converge on the same repo would be good. Then you could merge their work into the main branch time to time. I am also on Linux exclusively, and a canonical repo would be great.

Thx so much for developing and looking after LossyWAV.

Triza

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #83 –
@corrideat: Your version does not sit within the existing 1.4.x numbering system as it is based on the 1.4.0 source - also, 1.4.2 is already "taken".

@2012: Your previous efforts are appreciated.

@Triza: Good point. When I release 1.4.2, I will create a github repository (or use the existing one created by rtollert some time ago).
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)

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #84 –
@Nick.C: my LossyWAV is waiting for the next incarnation...

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #85 –
Looking forward to the new version! Also, a question: my primary use of lossyWAV is to transcode podcasts, downmix to mono and src to 32k. Aside from --limit 14512, are there any parameter changes you would recommend for this purpose?

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #86 –
Quote from: Musique-Rabbit on
@Nick.C: my LossyWAV is waiting for the next incarnation...

Apologies (I seem to be doing that rather a lot recently).

lossyWAV beta 1.4.1o 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)

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #87 –
My lossyWAV is alive, again!

Thanks, Nick.C!

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #88 –
lossyWAV 1.4.2 released here.
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)
 

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #89 –
Quick question - is it possible and/or has anyone every attempted to combine lossyFlac and correction file without going back to WAV format?

I recognise (and am considering) writing something that will combine the 2 decoded PCM streams (lossy + correction) and return a single lossless FLAC file.  (at the moment I only know of scripts that do this by de-FLACing each file to temp directory and the resulting files are then pased to lossyWAV so that the merge wav can be piped to the standard Flac encoder rather than doing everything, in memory, as one compiled program).

However it struct me that not only I could I do this all in memory, but perhaps I might be able to *combine directly* the 2 FLAC files without going via PCM and back to FLAC, this is could be quicker.

Note this would be for time-sensative operations like transcoding so that I could easily play music back losslessly on-the-fly with a single program; thus I wouldn't care so much if combining the 2 FLAC files resulted in a larger but valid FLAC representation than converting both back to PCM first as it would only exist for the life of the playback.

One last question - do any audio players support playback of both lossy and correction at the same time.  My understanding is that they wouldn't need to explicitly support lossyWav - just be configurable to play both Flac files in exact synchrony?

Thanks!

I'm guessing this isn't

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #90 –
With DeaDBeeF's author I got lossywav to work in DeaDBeeF. I use the following command:
lossywav - -q high --linkchannels -s f -m --maxclips 0 -w --bitdist --silent --stdout | flac - -b 512 -5 -f -o %o --ignore-chunk-sizes

I use Arch based distro and compiled lossywav from their AUR repo. I guess you have to change the quality settings according what you want to use. One problem though is that the logfile is created in /home/username/ and not in for example /home/username/music/targetfolder/ where the audio files end up.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #91 –
hi to everyone. i compared lossywav to wavpack hybrid lossy. I compared this to methods using audacity(inverting packed track and mix with original). And wavpack is much better in all songs examples - have less noise after packing. So i recommend to use wavpack hybrid mode. Hope this will be usefull for someone. Thank you

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #92 –
Quote from: theselector on
hi to everyone. i compared lossywav to wavpack hybrid lossy. I compared this to methods using audacity(inverting packed track and mix with original). And wavpack is much better in all songs examples - have less noise after packing. So i recommend to use wavpack hybrid mode. Hope this will be usefull for someone. Thank you

Making statements without any proof is a violation of the #TOS here.

If you want to make such a claim, write some extensive information about you test procedures, parameters and a whole lot more and provide double blind test results.

You're claiming something that is nonsense in the first place to my opinion.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #93 –
Has anyone encountered any issues with LossyWAV 1.4.2 handling 96 kHz 5.1 (6-channel) 24-bit WAV files? It gives me a bunch of errors that look like this:

Too much WAV information before 'data' chunk!
RIFF; 46464952-0000-0000-0000-000000000000; 00000000

And then it crashes.

Is there something I can do to the WAV files (at a file container level) to work around this problem? I'd prefer not to have to resample or dither the PCM just to make LossyWAV work.

Here's a MediaInfo snapshot of the WAV source I'm using:
Code: [Select]
Format                                   : Wave
File size                                : 432 MiB
Duration                                 : 4 min 22 s
Overall bit rate mode                    : Constant
Overall bit rate                         : 13.8 Mb/s
Writing application                      : Lavf58.17.100

Audio
Format                                   : PCM
Format settings                          : Little / Signed
Codec ID                                 : 00000001-0000-0010-8000-00AA00389B71
Duration                                 : 4 min 22 s
Bit rate mode                            : Constant
Bit rate                                 : 13.8 Mb/s
Channel(s)                               : 6 channels
Channel positions                        : Front: L C R, Side: L R, LFE
Sampling rate                            : 96.0 kHz
Bit depth                                : 24 bits
Stream size                              : 432 MiB (100%)

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #94 –
Maybe it is having a problem detecting the format correctly.

I am guessing that you might have a Riff64 file that might not be exactly like what lossywav expects. You could try converting it to riff32, given that the file size is less than 2GB.

If you use audacity, you could try file->export -> export as wav, other uncompressed formats, and there waveex (microsoft) and signed 24bit PCM.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #95 –
Looks like it was exported as WaveFormatExtensible instead of WaveFormatEx, probably to support the speaker coverage bits.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #96 –
Quote from: Fairy on
Quote from: theselector on
hi to everyone. i compared lossywav to wavpack hybrid lossy. I compared this to methods using audacity(inverting packed track and mix with original). And wavpack is much better in all songs examples - have less noise after packing. So i recommend to use wavpack hybrid mode. Hope this will be usefull for someone. Thank you

Making statements without any proof is a violation of the #TOS here.

If you want to make such a claim, write some extensive information about you test procedures, parameters and a whole lot more and provide double blind test results.

You're claiming something that is nonsense in the first place to my opinion.

It could be true. Wapack at same bitrate is better than lossywav with objectively less noise .  Lossyway noise moves in 6db steps while wavpack moves infinite steps from what I read in the past. OTOH Wavpack doesn't have a yet a true quality mode while lossywav does. This also might not have any impact if comparing strong settings like lossyway --extreme to wavpack -b550x4 .. wavpack is also expected to be 100% transparent and offering better quality [objective].  At more moderate bitrates (400k)  subjectively , Lossywav may have the advantage in very rare cases due to the quality mode . At lower rates like 250k wavpack may have a general advantage too .

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #97 –
Quote from: CitizenInsomniac on
Has anyone encountered any issues with LossyWAV 1.4.2 handling 96 kHz 5.1 (6-channel) 24-bit WAV files? It gives me a bunch of errors that look like this:
Too much WAV information before 'data' chunk!
RIFF; 46464952-0000-0000-0000-000000000000; 00000000

In case anyone runs into the same issue... Here's the workaround: just use FFmpeg to remux your WAV files with channel map set to 5.1 instead of 5.1(side) which is the FFmpeg default.

For example:
Code: [Select]
ffmpeg -y -i input_96khz_24b.wav -acodec pcm_s24le -af channelmap=channel_layout=5.1 output.wav

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #98 –
Glad that you found a solution to the issue.
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)

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #99 –
Is it possible to adjust block size? (if no, what's your prediction of difficulty to add it? I assume it's not just 1 variable, many things probably depend on it, etc)

(why: I was thinking of using LossyWav to reduce size of some high resolution (24 bit) records for long term storage/transcoding in a way that keeps them strictly not worse than a simple conversion to 16 bits per sample would do, while also keeping some extra precision only in quieter sections. AFAIK lossywav can be commanded to do this using parameters --dynamic and --static, but I found that in this mode of operation, the result compresses worse if FLAC is set to use 512 block size (in comparison to default FLAC settings), so it looks like this combination can work better with a different block size in lossywav.)
a fan of AutoEq + Meier Crossfeed