Skip to main content

Topic: lossyWAV 1.4.2 Development (was 1.5.0) (Read 24717 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • alter4
  • [*][*][*]
Re: lossyWAV 1.4.2 Development (was 1.5.0)
Reply #75
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.

  • GeSomeone
  • [*][*][*][*][*]
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.

  • Fairy
  • [*][*][*]
Re: lossyWAV 1.4.2 Development (was 1.5.0)
Reply #77
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.

  • Nick.C
  • [*][*][*][*][*]
  • Developer
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| FLAC -5 -e -p -b 512 -P=4096 -S-

  • corrideat
  • [*]
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

  • 2012
  • [*][*][*]
Re: lossyWAV 1.4.2 Development (was 1.5.0)
Reply #80
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
saldl: A lightweight well-featured CLI downloader optimized for speed and early preview.
https://saldl.github.io

  • Triza
  • [*][*][*][*]
Re: lossyWAV 1.4.2 Development (was 1.5.0)
Reply #81
Hello Nick and Corrideat,

Where is the canonical repository for the source code. I see people starting various repositories

https://github.com/MoSal/lossywav-for-posix
https://github.com/corrideat/lossywav

Not obvious which version they started their copy. I am not sure where I could get the latest source, either.

Cheers,

Triza

  • Triza
  • [*][*][*][*]
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
  • Last Edit: 13 August, 2016, 06:27:54 AM by Triza

  • Nick.C
  • [*][*][*][*][*]
  • Developer
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| FLAC -5 -e -p -b 512 -P=4096 -S-

Re: lossyWAV 1.4.2 Development (was 1.5.0)
Reply #84
@Nick.C: my LossyWAV is waiting for the next incarnation...

  • improb
  • [*]
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?

  • Nick.C
  • [*][*][*][*][*]
  • Developer
Re: lossyWAV 1.4.2 Development (was 1.5.0)
Reply #86
@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| FLAC -5 -e -p -b 512 -P=4096 -S-

Re: lossyWAV 1.4.2 Development (was 1.5.0)
Reply #87
My lossyWAV is alive, again!

Thanks, Nick.C!

  • Nick.C
  • [*][*][*][*][*]
  • Developer
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| FLAC -5 -e -p -b 512 -P=4096 -S-

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
  • Last Edit: 05 November, 2016, 12:20:43 PM by falloutphil

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.
  • Last Edit: 26 October, 2017, 12:43:04 PM by punkrockdude