Skip to main content
Topic: lossyWAV 1.4.0 Released (Read 43377 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lossyWAV 1.4.0 Released

Reply #75
Are you going to add mutithreading processing in order to speed up whole process? I have 8C/16T CPU and processing of movie track 5.1 takes to much time due single threaded code.


I suggest using Foobar2000 and process from there. It is capable to start more conversions simultaneously.

With the task manager you can set the amount of processors assigned to foobar. Setting too much CPU's can result in HDD seeking (overload) slowing things down. Just try with 4 first and build up from there keeping an eye on the system resources.


Your method is: Build 8 houses in the same time
But I prefer: Build 1 house 8 times faster

I was thinking about encoding multiple chunks of data (let's say 1min) in the same time and then combine all chunks into one FLAC file.
I think I can achieve that with something like this

ffmpeg.exe 00:00:00 00:00:00.999 -> lossywav -> flac encoder -> 01.flac
ffmpeg.exe 00:00:01 00:00:01.999 -> lossywav -> flac encoder -> 02.flac
ffmpeg.exe 00:00:02 00:00:02.999 -> lossywav -> flac encoder -> 03.flac

Unfortunately there is major problem. How to combine multiple flacs into one flac without RE-ENCODING?! Btw. Forget about copy /b method...


I get the point, but multi-cpu processing one file is a major change in code, just like the developer says. Many file compression programs have problems with multicore cpu's. You can use multi cpu's, but many times at the cost of compression ratio, because the data becomes uncomparable when it is sliced in separate chunks. For FLAC's this is less of a problem, but general data compression relies on big dictionaries...

I see no problem in the 8 houses method. Normally you have so much FLAC files that there is no gain in speed by processing 1 file by 8 cpu's.

lossyWAV 1.4.0 Released

Reply #76
I see no problem in the 8 houses method. Normally you have so much FLAC files that there is no gain in speed by processing 1 file by 8 cpu's.

This might be true if you compress an album in separate tracks, but as the original poster said "movie track 5.1 takes to much time".  The only mitigation is that when processing in a "pipe", at least lossywav and flac are separate processes  .
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.4.0 Released

Reply #77
Last question. Processing all channels at the same will be difficult to implement? I mainly work with 6 , 8 channel tracks so 6 , 8 times faster encoding would be still great on my xeon 8c/16t.


To process using more than a single thread would require a great deal of recoding to allow parallel processing rather than sequential processing.

Looking around, FFMPEG can be used to take a multi-channel audio file and split it into multiple mono files (I've tried it on a 6-channel file and it didn't take too long at all). If these files were processed using multiple instances of lossyWAV and then re-muxed into a single multi-channel audio file (I did this too - it worked well) then compressed with FLAC, I would expect that the overall processing time would be significantly reduced.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

lossyWAV 1.4.0 Released

Reply #78
Last question. Processing all channels at the same will be difficult to implement? I mainly work with 6 , 8 channel tracks so 6 , 8 times faster encoding would be still great on my xeon 8c/16t.


To process using more than a single thread would require a great deal of recoding to allow parallel processing rather than sequential processing.

Looking around, FFMPEG can be used to take a multi-channel audio file and split it into multiple mono files (I've tried it on a 6-channel file and it didn't take too long at all). If these files were processed using multiple instances of lossyWAV and then re-muxed into a single multi-channel audio file (I did this too - it worked well) then compressed with FLAC, I would expect that the overall processing time would be significantly reduced.


Nick,

A totally different trajectory here: do the following parameters (-a n and/or --feedback n) provide any additional benefits at high bitrates (Q5-7.5)?

Thanks in advance.

Alex
lossyWAV -q H | FLAC -5 ~= 480kbps
QAAC 320kbps

lossyWAV 1.4.0 Released

Reply #79
The suggestions for fb2k setup need updating, because using those examples on an WinXP SP3 system gave me nothing but problems until I went (using TAK setup as an example) from this...

/d /c C:\"Program Files"\Encoders\LossyWAV\lossywav - --quality extreme --silent --stdout|C:\"Program Files"\Encoders\TAK\Applications\takc -e -p2m -fsl512 -ihs -v -md5 - %d


...to this.


/d /c C:\LossyWAV\lossywav - --quality extreme --silent --stdout|C:\LossyWAV\takc -e -p2m -fsl512 -ihs -v -md5 - %d


I also, with LossyWAV 1.4.0 installation, found that I had to put all the encoders I wanted into the folder itself for anything to work at all, unlike before.

Ah, upgrading! Love that process! 


I ended up having to go through this stuff again with my new Windows 8.1 laptop. So I think, at this point, it's not a Windows problem, it's a LossyWAV problem.
ghostman

lossyWAV 1.4.0 Released

Reply #80
Anyone knows the command line in Linux? I use DeadBeeF so piping would be great! Regards.

lossyWAV 1.4.0 Released

Reply #81
I've noticed, also, a weird problem when creating a single LossyWAV file in fb2k. Before, I'd end up with a file that looked like this:


01. Until The Night.lossy.wv

Instead, I now get this:

01. Until The Night.lossy.wv.lossy.wv



Interestingly, I don't have this problem at all, whatsoever, in fb2k when I select an entire album to be encoded into LossyWAV files.

BTW: I've double-checked my settings. They're set up according to the instructions in the 1st post of this thread, so that's not the problem.


ghostman

lossyWAV 1.4.0 Released

Reply #82
Last question. Processing all channels at the same will be difficult to implement? I mainly work with 6 , 8 channel tracks so 6 , 8 times faster encoding would be still great on my xeon 8c/16t.


To process using more than a single thread would require a great deal of recoding to allow parallel processing rather than sequential processing.

Looking around, FFMPEG can be used to take a multi-channel audio file and split it into multiple mono files (I've tried it on a 6-channel file and it didn't take too long at all). If these files were processed using multiple instances of lossyWAV and then re-muxed into a single multi-channel audio file (I did this too - it worked well) then compressed with FLAC, I would expect that the overall processing time would be significantly reduced.


FWIW, I tried a lower level approach, that is using multi-threading support in libfftw3. That did not improve performance. In fact, lossywav ended up running slower. IIUC, libfftw3 was spending more time synchronizing than processing because the plans were too small.

lossyWAV 1.4.0 Released

Reply #83
FWIW, I tried a lower level approach, that is using multi-threading support in libfftw3.


I can tell you without even trying that this is going to fail.  Parallelizing an individual FFT does not make sense until you are orders of magnitude larger than anything used in audio.  Usually you only bother with large, higher dimensional FFTs.  Parallelizing a 512 point FFT would mean that each processor was doing nanoseconds worth of work before you had to synchronize

lossyWAV 1.4.0 Released

Reply #84
Something wrong with --check option. I used 64bit lossywav with the following command line. I got strange message in my windows console and then lossywav simply crashed.

Code: [Select]
     D:\temp\777>lossywav 6.wav --quality high  -c
     lossyWAV 1.4.0, Copyright (C) 2007-2014 Nick Currie. Copyleft.
     This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
     the extent permitted by law. <http://www.gnu.org/licenses/> for details.
     lossyWAV FACT Chunk not found. File not marked as processed.
     RIFF; 46464952-0000-0000-0000-000000000000; 00000000
     fmt; 20746D66-0000-0000-0000-000000000000; 00000010
     fact; 74636166-ACF3-11D3-8CD1-00C04F8EDB8A; 00000000
     data; 61746164-0000-0000-0000-000000000000; 030E2860
     ☺
     ; 000A0001-0000-0000-0000-000000000000; 000A0005
    
     Too much WAV information before 'data' chunk!

lossyWAV 1.4.0 Released

Reply #85
The check function does not process the file - it simply checks the file to determine whether it has already been processed - and was included to facilitate batch processing of files.

The key line is: "lossyWAV FACT Chunk not found. File not marked as processed." The program exits with "ERRORLEVEL=16" if the file is processed (i.e. the FACT chunk is found) and "ERRORLEVEL=0" if not.

lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

lossyWAV 1.4.0 Released

Reply #86
I tried
lossywav 6.wav  -c
before. The issue here why lossywav crashes after printing these lines. I tried different wav files, result the same - crash after printing line "Too much WAV information before 'data' chunk!"

lossyWAV 1.4.0 Released

Reply #87
Thanks for that - I'll have a look at it (it's been a while since I used "check" on anything as the FACT chunk is lost when data is piped in to FLAC).
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

lossyWAV 1.4.0 Released

Reply #88
Thanks guys!
One more question. Is it safe to use lossyWAV on 24bit-44k source and 16bit -48k source? What flac block size should be specified in each case? Sorry if it already has been clarified somewhere.

lossyWAV 1.4.0 Released

Reply #89
lossyWAV will process audio with sample-rates from 32 kHz to 384 kHz on sample bit-depths from 8 bit to 24 bit. The definition of "safe" in this context is unclear.

The processing block size for 44.1/48 kHz sample rates is 512 samples.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

lossyWAV 1.4.0 Released

Reply #90
When I say safe I mean safe for my ears  , in general I mean optimization for transparency for those bit depth/sample rate params. When I use 16bit 44k I am sure profile extreme is transparent, Can I be sure for 16bit 48k with same profile?

lossyWAV 1.4.0 Released

Reply #91
Can I be sure for 16bit 48k with same profile?


.... only by doing the same form of personal testing that you did to arrive at the conclusion that it was adequate for 16 bit / 44.1 kHz.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

lossyWAV 1.4.0 Released

Reply #92
The issue here why lossywav crashes after printing these lines. I tried different wav files, result the same - crash after printing line "Too much WAV information before 'data' chunk!"


Bug fixed in beta 1.4.1h [here]
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

lossyWAV 1.4.0 Released

Reply #93
Curious question:
Is there a way to store the encoding settings of lossywav as tag in FLAC?

lossyWAV 1.4.0 Released

Reply #94
If the audio file is processed to a WAV file then compressed using FLAC with --keep-foreign-metadata then the FACT chunk will be retained (this contains the lossyWAV settings).

If, however, the audio file is processed and piped to FLAC then the FACT chunk would be lost (as FLAC does not support piped additional chunks) so is not output.

The best way would be to add a user defined tag using a tagging tool. I would use the foobar2000 file properties dialog as I use that program to convert all of my lossless to lossyFLAC.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

lossyWAV 1.4.0 Released

Reply #95
Thank you for your help, Nick.

I had a more automatized solution for this in my mind. Adding tags to each file manually can be a lot of work after converting a lot of audio files.

Can tagging of lossyway settings in FLAC output file be done by script or something else?

lossyWAV 1.4.0 Released

Reply #96
There's no need to edit the tags individually.

In foobar2000 there does not seem to be a limit to the number of files that can be selected simultaneously when amending the properties - the whole processing/conversion batch could be selected and the tag added as easily as a single file.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848| FLAC -5 -e -p -b 512 -P=4096 -S-

lossyWAV 1.4.0 Released

Reply #97
I think it is time to change:
Code: [Select]
-o%d
to
Code: [Select]
-o %d
in the usage description! 

lossyWAV 1.4.0 Released

Reply #98
There's no need to edit the tags individually.

In foobar2000 there does not seem to be a limit to the number of files that can be selected simultaneously when amending the properties - the whole processing/conversion batch could be selected and the tag added as easily as a single file.


Thanks, Nick.

What about making that task easier by copying the lossywav setting info as text into a system variable or into clipboard?

lossyWAV 1.4.0 Released

Reply #99
I had a more automatized solution for this in my mind. Adding tags to each file manually can be a lot of work after converting a lot of audio files.

Can tagging of lossyway settings in FLAC output file be done by script or something else?

How do you convert your files?

 
SimplePortal 1.0.0 RC1 © 2008-2018