LameXP v4.21 Final · Build #2382 (2023-12-29)

[Atak_Snajpera]

Opus encoding does not work in ABR mode

LameXP v4.05 (Build #1094), compiled on 2012-08-21 at 21:38:19

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

C:/Users/Mama/AppData/Local/Temp/fb867800d75349b5bf17ed998fe27c63/lxp_flac.exe -d -F -f -o C:\Users\Mama\AppData\Local\Temp\fb867800d75349b5bf17ed998fe27c63\332ef1f30da44ea89ed1890f46a613a8.wav "C:\Users\Mama\Desktop\CryptidaliaFLAC\Rom Di Prisco\Cryptidalia\01 - Troposphere.flac"

flac 1.2.1, Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007 Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.

Exited with code: 0x0000

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

C:/Users/Mama/AppData/Local/Temp/fb867800d75349b5bf17ed998fe27c63/lxp_sox.exe --i C:/Users/Mama/AppData/Local/Temp/fb867800d75349b5bf17ed998fe27c63/332ef1f30da44ea89ed1890f46a613a8.wav

Input File : 'C:/Users/Mama/AppData/Local/Temp/fb867800d75349b5bf17ed998fe27c63/332ef1f30da44ea89ed1890f46a613a8.wav'
Channels : 2
Sample Rate : 44100
Precision : 16-bit
Duration : 00:05:39.26 = 14961152 samples = 25444.1 CDDA sectors
File Size : 59.8M
Bit Rate : 1.41M
Sample Encoding: 16-bit Signed Integer PCM

Exited with code: 0x0000

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

C:/Users/Mama/AppData/Local/Temp/fb867800d75349b5bf17ed998fe27c63/lxp_opusenc_ea7.exe -cvbr --music --comp 10 --framesize 20 --bitrate 64 --title Troposphere --artist "Rom Di Prisco" --comment album=Cryptidalia --comment genre=Electronic --comment "comment=Encoded with LameXP" --comment date=2010 --comment track=1 C:\Users\Mama\AppData\Local\Temp\fb867800d75349b5bf17ed998fe27c63\332ef1f30da44ea89ed1890f46a613a8.wav "C:\Users\Mama\Desktop\CryptidaliaFLAC\01 - Troposphere (3).opus"

Usage: opusenc [options] input_file output_file.opus
Encodes input_file using Opus. It can read the WAV, AIFF, or raw files.
General options:
-h, --help This help
-v, --version Version information
--quiet Quiet mode
input_file can be:
filename.wav file
- stdin
output_file can be:
filename.opus compressed file
- stdout
Encoding options:
--speech Optimize for speech
--music Optimize for music
--bitrate n.nnn Encoding bitrate in kbit/sec (6-256 per channel)
--vbr Use variable bitrate encoding (default)
--cvbr Use constrained variable bitrate encoding
--hard-cbr Use hard constant bitrate encoding
--comp n Encoding complexity (0-10, default: 10)
--framesize n Maximum frame size in milliseconds
(2.5, 5, 10, 20, 40, 60, default: 20)
--expect-loss Percentage packet loss to expect (default: 0)
--downmix-mono Downmix to mono
--downmix-stereo Downmix to stereo (if >2 channels)
--max-delay n Maximum container delay in milliseconds
(0-1000, default: 1000)
Diagnostic options:
--save-range file Saves check values for every frame to a file
--set-ctl-int x=y Pass the encoder control x with value y (advanced)
Preface with s: to direct the ctl to multistream s
This may be used multiple times
--uncoupled Use one mono stream per channel
Metadata options:
--comment Add the given string as an extra comment
This may be used multiple times
--artist Author of this track
--title Title for this track
Input options:
--raw Raw input
--raw-bits n Set bits/sample for raw input (default: 16)
--raw-rate n Set sampling rate for raw input (default: 48000)
--raw-chan n Set number of channels for raw input (default: 2)
--raw-endianness n 1 for bigendian, 0 for little (defaults to 0)
--ignorelength Always ignore the datalength in Wave headers
C:\Users\Mama\AppData\Local\Temp\fb867800d75349b5bf17ed998fe27c63\lxp_opusenc_ea7.exe: invalid option -- c

Exited with code: 0x0001


Regarding opus advanced settings

http://i.imgur.com/J4unJ.png

--music and --speech switch will be removed in official final version according to devs

[LoRd_MuldeR]

Thank you for the report. LameXP is passing "-cvbr", while it should be passing "--cvbr". I will fix this typo in the next build :o

Also I probably won't update the Opus binaries again before the 4.05 release, so "--music" and "--speech" will stay for now (although they don't do much, they don't hurt either).

[Atak_Snajpera]

Also I probably won't update the Opus binaries again before the 4.05 release, so "--music" and "--speech" will stay for now (although they don't do much, they don't hurt either).
As the matter of fact those switches do nothing so i would remove them anyway. I think it is better to just allow for Hybrid mode where encoder can dynamically switch between SILK and CELT modes.

Another thing. I wonder why user would like to lower Encoding Complexity and Frame Size?

[LoRd_MuldeR]

They do something. Though not what one may expect.

Opus operates in 3 modes:

1) SILK only.
2) Hybrid.
3) CELT only.

The mode is selected based on requested bitrate/quality. Not based on the nature of content as one might think.

All --speech and --music do (at this point) is shift the mode decision lower or higher (in that order).

Another thing. I wonder why user would like to lower Encoding Complexity and Frame Size?

Trade speed for quality, similar to the LAME algorithm quality option.

[Atak_Snajpera]

http://www.hydrogenaudio.org/forums/index.php?showtopic=86580&view=findpost&p=805845

Trade speed for quality, similar to the LAME algorithm quality option.
is this really a problem for current cpus? I would like to see an user who lowers encoding quality due to slow encoding times ;)

[Atak_Snajpera]

Another question. Why LameXP always dumps everything first to .wav instead of just using pipes? My HDD is old and slow and this is really a noticeable bottleneck when running 4 instances on my Q8200@2.8Ghz

[LoRd_MuldeR]

Because using pipes would require all encoders and all decoders to support reading input from STDIN and writing output to STDOUT.

Also: Even if we assume all tools could to this, what do you send over the pipe? Just the "raw" PCM samples? If so, how do you indicate the sample format? Does the GUI need to know the sample format the previous tool outputs (how?) and pass that info to the next tool in the chain via CLI arguments? Or does the previous tool have to prepend a "fake" Wave header (or whatever header) to the data, which the next tools is required to parse? Who defines all this and enforces the individual tool authors to make use of it? In reality, every audio CLI tools does things slightly differently. And I cannot fix or re-write them all!

After all, using Wave files seems to be the "least common denominator" for exchanging audio data between various CLI tools. Using pipes might be more elegant, but suffers from a lot of practical problems...

[Atak_Snajpera]

Because using pipes would require that all encoders and all decoders to support reading input from STDIN and writing output to STDOUT.
I have not checked yet but probably most of encoders support stdin . For the rest you can use oldschool method :)

Also: Even if we assume all tools could to this, what do you send over the pipe? Just the "raw" PCM samples? If so, how do you indicate the sample format? Does the GUI need to know the sample format and pass it to the next tool in the chain via CLI arguments? Or does the previous tool have to prepend a "fake" Wave header (or whatever header) to the data? Who defines all this and enforces the individual tool authors to make use of it?
No you send as .wav obviously. Have you tried ffmpeg as decoder?

[LoRd_MuldeR]

is this really a problem for current cpus? I would like to see an user who lowers encoding quality due to slow encoding times ;)

Encoding speed might matter more, when you convert a large number of audio files. Assume you have all your music collection with hundreds or thousands of files in format A on your HDD, but now your new standalone-player only accepts format B, so you have to convert them all. This can easily take several hours and then a 1.5x or 2x speed-up can matter a lot!

Also: In case of LAME, the default/recommended "algorithm complexity" is not the slowest one, but the third slowest one. We certainly can't force all people to use the slowest settings, because benefit over the default settings will be minimal while encoding-speed will be a lot slower. Still some people don't care about speed and might want to user even slower settings than the default.

No you send as .wav obviously. Have you tried ffmpeg as decoder?

Sending Wave/RIFF files over a pipe is technically impossible, because of how the RIFF format is defined. The size of each Chunk must be defined at the beginning of each Chunk, but at the moment when you start writing a Chunk you very often cannot know how big it will be in the end. With a physical file, you simply can seek back and "fix" the Chunk header at the very end. With a pipe you obviously can't!

You can send some kind of "fake" Wave header (with "blank" size fields), indeed. But this requires the next tool in the chain to (a) expect a Wave header over the pipe and (b) know about your hack...

I have not checked yet but probably most of encoders support stdin.

Many decoders don't support writing to STDOUT, especially for the more exotic formats. Or they don't write to STDOUT in the "format" we would like to have.

For the rest you can use oldschool method

Supporting both methods, passing the data by Wave files and via Pipe, would add even more complexity plus more things to test - for every single CLI tool. No, thanks ;)

Also: If the data is passed via pipe, how does the GUI determine the sample format that comes out of the decoder?

The GUI has to know this, because sometimes the output format (e.g. sample-rate or bit-depth) the decoder spits out is not acceptable for the encoder and we need to convert via SoX!

[Atak_Snajpera]

here is how i convert .FLAC to lossy formats without intermediate .wavs

.FLAC to .OPUS
ffmpeg.exe -i "01 - Troposphere.flac" -f wav - | "opusenc.exe" --bitrate 64 - "01 - Troposphere.opus"

.FLAC to .OGG VORBIS
ffmpeg.exe -i "01 - Troposphere.flac" -f wav - | "oggenc.exe" -Q -q 0 - -o "01 - Troposphere.ogg"

.FLAC to .AAC
ffmpeg.exe -i "01 - Troposphere.flac" -f wav - | "fhgaacenc.exe" --profile he --cbr 64 --adts --ignorelength - "01 - Troposphere.aac"

.FLAC to .AC3
ffmpeg.exe -i "01 - Troposphere.flac" -f wav - | "aften.exe" -readtoeof 1 -b 192 - "01 - Troposphere.ac3"

[LoRd_MuldeR]

Just because one decoder/encoder combination works this way, doesn't mean we can use it in general ;)

It has to work with all decoders, all encoders as well as all filters that may be use optionally. Unfortunately, this very often does not work as intended, because of the various reasons explained before.

Also, how does the GUI determine the sample format in your example? As said before, many encoders are limited in what sample-rates, channel-count or bit-depth they accept as input...

(Thus the GUI must be able to determine what sample format the decoder is actually spitting out and it might required to insert an instance of SoX for the required conversion)

[Atak_Snajpera]

Just because one decoder/encoder combination works this way, doesn't mean we can use it in general ;)

It works for all encoders i tried see here again (http://forum.doom9.org/showthread.php?p=1588090#post1588090)

Also, how does the GUI determine the sample format in your example? As said before, many encoders are limited in what sample-rates, channel-count or bit-depth they accept as input...
mediainfo can extract frequenzy and channel count from source file. Then you can perform resampling or downmixing in ffmpeg directly! (-ac 2 -ar 48000)

[manolito]

Hey Atak,

I like your method using ffmpeg decoded output with a pipe...:)
Could you write a simple and small GUI which just takes the parameters and passes them to the command line?


Cheers
manolito

[LoRd_MuldeR]

It works for all encoders i tried see here again (http://forum.doom9.org/showthread.php?p=1588090#post1588090)

So it works with FFmpeg as the decoders and all encoders you have tested. That's one thing. But...

LameXP is using a variety of decoders (even some for rather "exotic" formats). There also are optional filters that might be between the encoder and decoder.

I'm not planning to add FFmpeg as decoder or to replace the current decoders with FFmpeg.

That's because FFmpeg is rather big and rather complex to build. I prefer to have individual decoders for each format, so I can maintain (update/patch) them more easily...

And of course switching over to FFmpeg would mean I had to rewrite large portions of the program, which I don't have the time/motivation for :devil:

mediainfo can extract frequenzy and channel count from source file. Then you can perform resampling or downmixing in ffmpeg directly! (-ac 2 -ar 48000)

The info provided by MediaInfo is about the compressed source file. What I need is the info of the uncompressed data that the decoder spits out.

For example, most compressed audio formats don't have a "bit depth" per se. It's up to the decoder to output the decompressed audio as 16-Bit Integer or 24-Bit Integer or 32-Bit IEEE Float.

Thus for MediaInfo it is impossible to know which "bit depth" the decoder is going to put out. It's not a property that can be "detected" form the compressed file...

(But we have to know it, because some encoders don't like Float input. Or they even reject everything put 16-Bit Integer)

[Atak_Snajpera]

The info provided by MediaInfo is about the compressed source file. What I need is the info of the uncompressed data that the decoder spits out.

For example, most compressed audio formats don't have a "bit depth" per se. It's up to the decoder to output the decompressed audio as 16-Bit Integer or 24-Bit Integer or 32-Bit IEEE Float.

Thus for MediaInfo it is impossible to know which "bit depth" the decoder is going to put out. It's not a property that can be "detected" form the compressed file...

(But we have to know it, because some encoders don't like Float input. Or they even reject everything put 16-Bit Integer)
as well as channel count , frequency YOU CAN also FORCE BITDEPTH (-acodec pcm_s16le) in FFMPEG so I is no problem here.

final example 5.1 to stereo
ffmpeg.exe -i "6channels-24BIT.dts" -acodec pcm_s16le -ac 2 -ar 44100 -f wav - | "opusenc.exe" --bitrate 64 - "2channels.opus"

That's because FFmpeg is rather big and rather complex to build. I prefer to have individual decoders for each format, so I can maintain (update/patch) them more easily...
And who says that you have to do everything on your own . Just grab latest build from http://ffmpeg.zeranoe.com/builds/

There also are optional filters that might be between the encoder and decoder.
what filters? Normalization?

And of course switching over to FFmpeg would mean I had to rewrite large portions of the program, which I don't have the time/motivation for
This should be on todo list for LameXP 5.0 version ;)

[LoRd_MuldeR]

LameXP v4.05 RC-2
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2012-08-22/

Changes between v4.04 and v4.05:
* Added support for Opus Audio Codec, based on Opus-Tools v0.1.4 (2012-08-16) by Xiph.org/Mozilla
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated Qt runtime libraries to v4.8.2 (2012-05-22), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.14.4 (2012-07-26), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.59 (2012-08-08), compiled with ICL 12.1.7 and MSVC 10.0
* Updated optional add-ins for QAAC encoder and FHG AAC encoder (see FAQ doc (http://lamexp.sourceforge.net/doc/FAQ.html#71a113b0) for details)
* Updated DCA Enc to v2 (2012-04-19), compiled with ICL 12.1.7 and MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files
* Fixed a problem with Cue Sheet import and files that contain trailing dots in their name
* Workaround for a bug (feature?) of Qt's command-line parser that screwed up some arguments

If you found any regressions in version 4.05, please report now ;)

[pururin]

as well as channel count , frequency YOU CAN also FORCE BITDEPTH (-acodec pcm_s16le) in FFMPEG so I is no problem here.
(High)Quality may be the problem for those who concern.
Downmixing may be simple, but Sampling Rate resampling and Bit depth conversion can be rather complex.

I think FFMPEG resampler is quite poor compared to other famous (free) ones out there. (etc. eac3to, SoX, Foobar2000, r8brain)
See here: http://src.infinitewave.ca/ for comparison.
And does FFMPEG have proper dithering when converting bit depth? I don't know for sure.

If I understand correctly, LameXP use SoX for resampling and dithering, right? Does LameXP applies dithering when decoder output 24-bit(or more) intermediate file then having to encode to 16-bit final result?

[LoRd_MuldeR]

If I understand correctly, LameXP use SoX for resampling and dithering, right? Does LameXP applies dithering when decoder output 24-bit(or more) intermediate file then having to encode to 16-bit final result?

That's correct. LameXP uses SoX for resampling and also bit-depth conversion, iff such thing is required (or requested by the user).

LameXP doesn't perfrom/request any dithering explicitly, but the SoX manpage says:
Specifically, by default, SoX automatically adds TPDF dither when the output bit-depth is less than 24 and any of the following are true:
• bit-depth reduction has been specified explicitly using a command-line option
• the output file format supports only bit-depths lower than that of the input file format
• an effect has increased effective bit-depth within the internal processing chain

[pururin]

For example, most compressed audio formats don't have a "bit depth" per se. It's up to the decoder to output the decompressed audio as 16-Bit Integer or 24-Bit Integer or 32-Bit IEEE Float.

As I've experimented so far, when convert from lossy format EVERY decoders just output to the same 16-Bit WAVE format
(with only one exception when convert mp3→mp3 which process directly within lame.exe). Converting from lossless format the intermediate wave's bit depth is as source, except few situations(e.g. 24-bit to DCA) where SoX comes when needed.

ac3, dts(AC3filter), aac(faad), mp3, vorbis, wma, musepack, opus and so on, everything got decoded to 16-Bit Integer, I think this is not very good.
Like when transcoding dts or ac3 track from blu-ray/movies it'd be better not to downconvert them to 16-bit int beforehand.
Because lossy audio has no bit depth so it usually got decoded at higher precision (often 32-bit Float) if I get it right, e.g. Eac3to internally works at 64-bit then dither to 32/24 bit depends on the encoder, meGUI using NicAudio reports "Bits per sample: 32" decoding, not sure about foobar2000's converter but IIRC it works 32-bit float internally.


Another thing I observed is when encoding 'medium-large?' audio files in multi-threading it got even slower than consecutive single-threading and CPU load is quite a bit low (about 13-24%). Like encoding 24-bit 5.1 flac tracks 24-minutes long each (~400MB) with either 2 or 4 instances running. I guess this is due to HDD bottleneck although my HDD is quite new and fast.

Consider 2 thing above, Atak does have a point I think. So far I really like LameXP the most but if there is an alternate way(?) to the (16-bit)intermediate wave file would be good. Also CPU power is not an issue these days.

-Also thanks a lot for the answer about dithering!

[LoRd_MuldeR]

Another thing I observed is when encoding 'medium-large?' audio files in multi-threading it got even slower than consecutive single-threading and CPU load is quite a bit low (about 13-24%). Like encoding 24-bit 5.1 flac tracks 24-minutes long each (~400MB) with either 2 or 4 instances running.

I guess this can happen due to HDD thrashing. It's probably more a problem of IOPS when concurrently reading/writing multiple Temp files than a problem of throughput.

HDD's are rather slow for random access, because of the seeking time (for repositioning the read/write head) and the rotation delay.

For this reason, LameXP already uses a rather "conservative" choice for the default thread count. Using "num_threads = num_cpu_cores" can be bad in terms of HDD thrashing.

Fortunately this problem will be resolved soon, as more and more people are switching to SSD's nowadays, at least for the OS partition (including the TEMP folder).

Consider 2 thing above, Atak does have a point I think. So far I really like LameXP the most but if there is an alternate way(?) to the (16-bit)intermediate wave file would be good. Also CPU power is not an issue these days.

I agree that using pipes (at least where possible) would be desirable. But, as discussed before, there are various practical problems to check and resolve. Most of them probably do have some kind of solution. But it still needs to be figured out, it needs to be implemented and then it needs to be tested. So that's not something you do on a rainy Sunday.

Furthermore LameXP currently uses several "stages" within each processing thread. These are "decoding", "analyzing", "filtering" and finally "encoding". And they are run one after the other, independently.

When using pipes, everything would essentially happen at the same time. Good in terms of parallelization. A nightmare for the design of the software, which currently tries to keep those tasks as isolated as possible. The more components of the software need to cooperate directly (and thus need to know about each other), the more dependencies we get. Those dependencies make maintenance and testing very difficult.

After all, such a fundamental re-design is probably not going to happen any time soon :devil:

[Atak_Snajpera]

i wonder if single ssd would be fast enough for 8 instances (amd fx 8xxx) during flac conversion?

[LoRd_MuldeR]

i wonder if single ssd would be fast enough for 8 instances (amd fx 8xxx) during flac conversion?

FLAC of course is kind of a problematic case, because it not only needs to read the uncompressed PCM source, but also needs to write the only slightly compressed FLAC data.

But you can calculate:
hdd_bandwidth_needed = number_of_instances * flac_throughput_per_instance * 1.66

Here flac_throughput_per_instance is the maximum throughput of a single FLAC instance in "bytes encoded per second" on your system (regarding the input only).
Also I am assuming a compression factor of approximately 2/3, so we use the factor 1.66 for writing the output. hdd_bandwidth_needed is then the "bytes per second" we'd have to transfer from/to the SSD.
On my system flac_throughput_per_instance is about 9 MByte/s (a single instance took ~5 sec to encode a 45 MB Wav file), so we'd have to transfer ~15 MByte/s per instance.
Current SATA 6G SSD's should be able to handle at least 300 MByte/s. So, roughly, we would have room to run at least ~20 instances in parallel without having to worry about I/O bottleneck here...

[LoRd_MuldeR]

LameXP v4.05 RC-3

Changes between v4.04 and v4.05:
* Added support for Opus Audio Codec, based on Opus-Tools v0.1.4 (2012-08-16) by Xiph.org/Mozilla
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated Qt runtime libraries to v4.8.2 (2012-05-22), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.14.4 (2012-07-26), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.59 (2012-08-08), compiled with ICL 12.1.7 and MSVC 10.0
* Updated optional add-ins for QAAC encoder and FHG AAC encoder (see FAQ doc (http://lamexp.sourceforge.net/doc/FAQ.html#71a113b0) for details)
* Updated DCA Enc to v2 (2012-04-19), compiled with ICL 12.1.7 and MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files
* Fixed a problem with Cue Sheet import and files that contain trailing dots in their name
* Workaround for a bug (feature?) of Qt's command-line parser that screwed up some arguments

If you found any regressions in version 4.05, please report now ;)

[Atak_Snajpera]

What do you think about lossyWAV as optional pre-processor for FLAC? BTW. I know how it works.

[LoRd_MuldeR]

What do you think about lossyWAV as optional pre-processor for FLAC? BTW. I know how it works.

How does it work then? I haven't used it yet.

As far as I understand, this tool (dynamically) reduce the bit-depth of the PCM audio, which makes the audio file more "compressible" for lossless compression, such as FLAC.

So does it actually output a lower bid-depth Wave file (e.g. input is 16-Bit output is 8-Bit) or is the output Wave file still the same bit-depth as the input and only the "content" is changed?

Most important: What would be the most appropriate command-line to use lossyWAV as a pre-processor for FLAC ??? :confused:

I may indeed add this to LameXP (optionally), if it really reduces the size of FLAC compressed files without any "bad" side-effects - except for the "subtle" quality loss that is to be expected.

But I wonder: If it works as nice as described in the Hydrogenaudio thread, why the author of FLAC hasn't integrated this yet? Having to apply it separately looks like a workaround...

[Atak_Snajpera]

So does it actually output a lower bid-depth Wave file (e.g. input is 16-Bit output is 8-Bit) or is the output Wave file still the same bit-depth as the input and only the "content" is changed?
bit-depth is still 16 but content is changed. Some bit will be zeroized (empty-bits).

Most important: What would be the most appropriate command-line to use lossyWAV as a pre-processor for FLAC ???
lossywav.exe input.wav --stdout --standard --silent | flac.exe - -b 512 -o "lossy.flac"

Important note

NB: when encoding using a lossless codec, please ensure that the block size of the lossless codec matches that of lossyWAV (default = 512 samples). If this is not done then the lossless encoding of the processed WAV file will (almost certainly) be larger than it would otherwise have been. This is achieved by adding the "Encoder Parameters" in the table above to the command line of the lossless codec in question.


I may indeed add this to LameXP (optionally), if it really reduces the size of FLAC compressed files without any "bad" side-effects - except for the "subtle" quality loss that is to be expected.
at least --standard is 99% transparent because noise is still below human hearing range.

But I wonder: If it works as nice as described in the Hydrogenaudio thread, why the author of FLAC hasn't integrated this yet? Having to apply it separately looks like a workaround...
Because lossy pre-proccesor might not look right for lossless encoder even as option?

[pururin]

Adding lossyWAV is very useful indeed! I do hope you will add this to LameXP, LoRd_MuldeR.

Bit depth to be reduced is determined block-by-block, 24→11, 24→20 ,etc. This is better/smarter than simple TPDF dither where every block got chop off from 24→16 bit. Sorta like VBR comparing to CBR I think.
This is very good for ones who don't want to store bloated hight bit depth lossless file(which has no perceptual benefit) but don't want to convert it to lossy codecs which prone to certain artefacts and unsuitable for transcoding.

[LoRd_MuldeR]

I had a quick look at lossyWave.

It's written in Delphi, and, which isn't much of surprise, doesn't support Unicode file names. I could repair this, I think. But only if lossyWave did compile with my Delphi 7 Pro, which it doesn't. There's some code that tries to write to a constant memory location. No idea if that is a bug or intentional. Maybe that was allowed in some older Delphi version - or has been made legal in a newer version. I have no idea. For my Delphi version it's a compiler error - which makes sense to me.

Further on, lossyWave tries to load libfftw DLL. At least on my system it crashed when libfftw was found. I probably had a wrong/incompatible version. Again, no idea. Anyway, lossyWave shouldn't try to use an incompatible version and crash. As using libfftw seems to be optional anyway, I would have to disable that "feature". Last but not least, FLAC complained about an "unknown" chunk in the Wave file produced by lossyWave and it exited with an error code. Didn't look closer what the cause is.

After all, there is much work left, before this tool can be integrated. Not sure if I am interested to do that (soon).

[Atak_Snajpera]

another issue is lossywav does not support wavs larger than 4gb. also it does not have --ignorelength switch for piping directly large flacs to lossywav.

another issue. lossywav is not multithreaded. basic idea is to process each channel at the same time.

good news is that user at hydrogenaudio almost finished porting to C++

[LoRd_MuldeR]

LameXP v4.05 has been released :)
http://sourceforge.net/projects/lamexp/files/

Changes between v4.04 and v4.05 [2012-09-03]:
* Added support for Opus Audio Codec, based on Opus-Tools v0.1.4 (2012-08-16) by Xiph.org/Mozilla
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated Qt runtime libraries to v4.8.2 (2012-05-22), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.14.4 (2012-07-26), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.59 (2012-08-08), compiled with ICL 12.1.7 and MSVC 10.0
* Updated optional add-ins for QAAC encoder and FHG AAC encoder (see FAQ doc (http://lamexp.sourceforge.net/doc/FAQ.html#71a113b0) for details)
* Updated DCA Enc to v2 (2012-04-19), compiled with ICL 12.1.7 and MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files
* Fixed a problem with Cue Sheet import and files that contain trailing dots in their name
* Workaround for a bug (feature?) of Qt's command-line parser that screwed up some arguments

[pururin]

LameXP v4.05 has been released :)
Finally :thanks:

[manolito]

I have a problem with 4.05 final:

I specified my LameXP temp folder as a drive with 50 GB free space. Nevertheless LameXP shows the size of my temp folder as only 5 GB, which is exactly the free space on my system drive with the Windows default temp folder.

Does LameXP ignore my temp folder setting?


Cheers
manolito


//Edit
Yes, LameXP does ignore my settings for its temp folder. I just decoded an AAC audio file to WAV, my LameXP temp folder is set to I:\ , but the AAC file is decoded to my "documents and settings\username\local settings\app data\LoRd_MuldeR" folder. Not good...

//Edit2
Went back to version 4.04 final, and this version does not have this issue. So this is a regression which should be fixed...

//Edit3
It looks like the entry
AdvancedOptions\TempDirectory\UseCustomPath=
in the config.ini file is reversed. Custom path will be used if the entry is "False" which is the opposite of the desired behavior.

I generally question the method how LameXP just decodes a compressed audio file to WAV. The decoded output is saved in the temp folder first and then copied over to the target folder. Just a big waste of time IMO...

[LoRd_MuldeR]

There was a bug which caused the "Store temporary files in the system's default TEMP folder" check box to be initialized wrongly (inverted to what it should be) :o

The "TempDirectory\UseCustomPath" setting defaults to FALSE, so the aforementioned checkbox should be checked initially. Instead, as you may have noticed, it currently is un-checked initially.

Because you do want to use a "custom" TEMP folder, you'll have to check and then un-check the checkbox once. This will set "TempDirectory\UseCustomPath" to TRUE, as desired.

Note that while the checkbox is initialized wrongly, switching the checkbox manually will store/apply the correct (expected) value. Though, once you restart LameXP, you'll see the "wrong" state again.

The regression has been fixed in revision a4e78633e68a1eea16b33da0f5e3d2e1f84d579b (https://github.com/lordmulder/LameXP/commit/a4e78633e68a1eea16b33da0f5e3d2e1f84d579b). As this is more a "cosmetic" problem, I won't release an "emergency" update because of this.

(After four Beta releases plus three Release Candidates, you are the first person to report this issue. I noticed this by chance and fixed it three days ago)

[manolito]

Thx...:):):)

Cheers
manolito

[LoRd_MuldeR]

BTW: If anybody wonders why on the LameXP SourceForge project site (http://sourceforge.net/projects/lamexp/) version 4.04 still is offered as the "latest version" (default download), but that download link actually goes nowhere, then please note that this is a SourceForge bug. For the very same reason some of the folders in the "files" section currently appear empty (e.g. some of the sub-folders under "Old Releases"), although they do contain files. I cannot do anything about that at the moment. The problem has been reported to the SF support about a week ago and the ticket is in "assigned" state now. Hopefully they are working on it...

Seems to be resolved now :)

[datauser]

I tried using this program, but unfortunately LameXP 4.05 crashes giving the error message in the log that...

The decoded file exceeds 4GB, problems might occur.

My input file was a 448kbps ac-3(5.1) and I wanted to output it to 320kbps mp3. I get the same error even if I lower it to 192kbps and so on. I'm using XP pro with ntfs partition, not FAT32.:(

[LoRd_MuldeR]

The error message is quite clear: You ran into the 4 GB file size limit :eek:

This means that the decoded Wave file exceeds a size 4 GB, which is not supported by the Wave/RIFF file format. It has absolutely nothing to do with the file system. The problem is that Wave files consist of (nested) RIFF chunks and that the "size" field of a RIFF chunk is only 32-Bit in size. Thus the total size of the outer "WAVE" chunk, which contains everything else, is limited to 2^32 bytes, i.e. 4 GB. This is a problem of how the Wave format was standardized years ago and we cannot do anything about that. Some programs, such as Valdec (the AC3-decoder from AC3-Filter Tools) create a RF64 (http://en.wikipedia.org/wiki/RF64) file (instead of a "standard" Wave file) in case the size exceeds 4 GB. However most audio tools, including the LAME MP3 encoder, do not support reading RF64 files yet. Unless RF64 gets adopted by all relevant tools, we are stuck here...

And now please don't start yet another discussion about using pipes instead of intermediate Wave files, I know about that possibility and also about the new problems that would arise :p

(BTW: The program does not actually crash, it just fails to convert the file, right?)

[manolito]

@datauser
This problem has been discussed before:
http://forum.doom9.org/showthread.php?p=1573059#post1573059
For such sources you need to use conversion software which does not depend on intermediate WAV files (ffmpeg, BeLight...)


Cheers
manolito

[datauser]

Thanks manolito. Pity, because this is really promising software. Back to belight for me then!

[LoRd_MuldeR]

LameXP v4.06 Beta-1

Changes between v4.05 and v4.06 [unreleased]:
* Updated Opus encoder/decoder libraries to v1.0.1 and Opus-Tools to v0.1.5 (2012-09-22)
* Updated mpg123 decoder to v1.14.4+ (2012-09-24), compiled with GCC 4.7.1
* Updated Qt runtime libraries to v4.8.3 (2012-09-13), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.60 (2012-09-07), compiled with ICL 12.1.7 and MSVC 10.0
* Fixed a bug with the "Store temporary files in your system's default TEMP director" checkbox
* Fixed a regression in Qt v4.8.3 that broke Drag&Drop support (details #1 (https://bugreports.qt-project.org/browse/QTBUG-27265)) (details #2 (https://codereview.qt-project.org/35297))
* Reworked the "About..." dialog – now using a custom dialog instead of message boxes

Please put special attention on Drag&Drop. The latest Qt release (v4.8.3) broke Drag&Drop on the Windows platform. I applied a patch (from Qt bug-tracker) that is supposed to fix it.

[LoRd_MuldeR]

LameXP v4.06 Beta-2

Changes between v4.05 and v4.06 [unreleased]:
* Updated Opus encoder/decoder libraries to v1.0.1 and Opus-Tools to v0.1.5 (2012-09-22)
* Updated mpg123 decoder to v1.14.4+ (2012-09-24), compiled with GCC 4.7.1
* Updated Qt runtime libraries to v4.8.3 (2012-09-13), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.60 (2012-09-07), compiled with ICL 12.1.7 and MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Fixed a bug with the "Store temporary files in your system's default TEMP director" checkbox
* Fixed a regression in Qt v4.8.3 that broke Drag&Drop support (details #1 (https://bugreports.qt-project.org/browse/QTBUG-27265)) (details #2 (https://codereview.qt-project.org/35297))
* Reworked the "About..." dialog – now using a custom dialog instead of message boxes

[LoRd_MuldeR]

LameXP v4.06 Beta-3

Changes between v4.05 and v4.06 [unreleased]:
* Updated Opus encoder/decoder libraries to v1.0.1 and Opus-Tools to v0.1.5 (2012-09-22)
* Updated mpg123 decoder to v1.14.4+ (2012-09-24), compiled with GCC 4.7.1
* Updated Qt runtime libraries to v4.8.3 (2012-09-13), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.60 (2012-09-07), compiled with ICL 12.1.7 and MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Fixed a bug with the "Store temporary files in your system's default TEMP director" checkbox
* Fixed a regression in Qt v4.8.3 that broke Drag&Drop support (details #1 (https://bugreports.qt-project.org/browse/QTBUG-27265)) (details #2 (https://codereview.qt-project.org/35297))
* Reworked the "About..." dialog – now using a custom dialog instead of message boxes

[LoRd_MuldeR]

LameXP v4.06 RC-1

Changes between v4.05 and v4.06 [unreleased]:
* Updated Opus encoder/decoder libraries to v1.0.1 and Opus-Tools to v0.1.5 (2012-09-22)
* Updated mpg123 decoder to v1.14.4+ (2012-09-24), compiled with GCC 4.7.1
* Updated Qt runtime libraries to v4.8.3 (2012-09-13), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.60 (2012-09-07), compiled with ICL 12.1.7 and MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Fixed a bug with the "Store temporary files in your system's default TEMP director" checkbox
* Fixed a regression in Qt v4.8.3 that broke Drag&Drop support (details #1 (https://bugreports.qt-project.org/browse/QTBUG-27265)) (details #2 (https://codereview.qt-project.org/35297))
* Reworked the "About..." dialog – now using a custom dialog instead of message boxes

[Motenai Yoda]

As I said some time ago, can u add a checkbox to use redundant directory search as default?
or where input is/are directory(s)?

thanks

Also the wow! sound on license accepting are little too loud imho.
And I notice it fails to decode aac input files.

LameXP v4.06 (Build #1154), compiled on 2012-10-19 at 20:57:22

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

C:/Users/Casa/AppData/Local/Temp/14fa19c6994f4e3390caed3654a3579c/lxp_faad.exe -o C:\Users\Casa\AppData\Local\Temp\14fa19c6994f4e3390caed3654a3579c\ae330d2e1a4f4634994ee2943ec38e3c.wav "C:\Users\Casa\Music\Users\Casa\Downloads\some music.mp4"

*********** Ahead Software MPEG-4 AAC Decoder V2.7 ******************
Build: Aug 16 2011
Copyright 2002-2004: Ahead Software AG
http://www.audiocoding.com
Floating point version
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License.
**************************************************************************
C:\Users\Casa\Music\Users\Casa\Downloads\some music.mp4 file info:
LC AAC 214.853 secs, 2 ch, 44100 Hz
track: 2
artist: some music
album: some music
comment: Convertito con LameXP
date: 2005
genre: Rock
title: Do You Want To
tool: qaac 1.39, CoreAudioToolbox 7.9.7.8, AAC-LC Encoder, TVBR q45, Quality 96
iTunSMPB: 00000000 00000840 000002A4 000000000090AD1C 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
---------------------
| Config: 2 Ch |
---------------------
| Ch | Position |
---------------------
| 00 | Left front |
| 01 | Right front |
---------------------

Exited with code: 0xC0000409

[LoRd_MuldeR]

And I notice it fails to decode aac input files.Exited with code: 0xC0000409

Exit code "0xC0000409" indicates that FAAD2 has crashed with STATUS_STACK_BUFFER_OVERRUN :eek:

I don't know if this is caused by a bad AAC/MP4 file or by a bug in FAAD2. Anyway, even if the AAC file is borked, FAAD2 shouldn't crash, but throw a warning and exit cleanly.

But, as I'm not a FAAD2 developer, I probably can't fix this. Also it seems the development of FAAD2 has stopped since 2009, so chances for a fix don't look good...

As I said some time ago, can u add a checkbox to use redundant directory search as default?

Well, if I remember correctly, you wanted that folders are added recursively (not "redundant") when added via Drag&Drop. Right?

As I suggested back then, I already implemented the feature that, if a folder is dropped onto LameXP and the folder itself doesn't contain any files, it will added recursively.

Default behavior still is unchanged though: If the folder does contain files, then it will not be added in a recursive way - only the files in that folder are added.

That's because adding folders recursively can take a lot of time! If you still need an option for that, I can add that for one of the next versions (it's too late for v4.06 now).

[LoRd_MuldeR]

LameXP v4.06 RC-2

Changes between v4.05 and v4.06 [unreleased]:
* Updated Opus encoder/decoder libraries to v1.0.1 and Opus-Tools to v0.1.5 (2012-09-22)
* Updated mpg123 decoder to v1.14.4+ (2012-09-24), compiled with GCC 4.7.1
* Updated Qt runtime libraries to v4.8.3 (2012-09-13), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.60 (2012-09-07), compiled with ICL 12.1.7 and MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Fixed a bug with the "Store temporary files in your system's default TEMP director" checkbox
* Fixed a regression in Qt v4.8.3 that broke Drag&Drop support (details #1 (https://bugreports.qt-project.org/browse/QTBUG-27265)) (details #2 (https://codereview.qt-project.org/35297))
* Reworked the "About..." dialog – now using a custom dialog instead of message boxes

[Motenai Yoda]

I don't know if this is caused by a bad AAC/MP4 file or by a bug in FAAD2. Anyway, even if the AAC file is borked, FAAD2 shouldn't crash, but throw a warning and exit cleanly.
can other decoder can't be used if releaved? like for aac encoder?

neroAacDec.exe can work?

the file is made with lamexp and qaac.

As I suggested back then, I already implemented the feature that, if a folder is dropped onto LameXP and the folder itself doesn't contain any files, it will added recursively.
Ah ok! But if it contain files but are invalid (like a txt or an image)? Or adding some folders "simultaneously"?

ok I tried with "lxp_faad.exe" by cmd and crash at the end, but do the wav! also neroAacDec.exe work.

now I'm trying with another file and work without crash... bah.

maybe should be a folder\name problem?

[LoRd_MuldeR]

can other decoder can't be used if releaved? like for aac encoder?

neroAacDec.exe can work?

the file is made with lamexp and qaac.

The Nero AAC decoder doesn't support .aac files (ADTS format), only AAC wrapped in a MP4 container. FAAD2 supports both.

Also I can't include the Nero AAC decoder into LameXP for legal reasons, so everything from the Nero AAC package has to remain an optional add-in.

If necessary, I could change LameXP to use the Nero AAC decoder instead of FAAD2, if available and if the AAC file is using the MP4 format.


Ah ok! But if it contain files but are invalid (like a txt or an image)? Or adding some folders "simultaneously"?

ok I tried with "lxp_faad.exe" form cmd and crash at the end, but do the wav! also neroAacDec.exe work.

now I'm trying with another file and work without crash... bah.

maybe should be a folder\name problem?

I don't think this is a problem with the file/folder name. All tools used by LameXP should be Unicode-safe. But you can easily find out by renaming the AAC/MP4 file and trying again ;)

By the way: Can you share the "problematic" file via PM please?

[Motenai Yoda]

I don't think this is a problem with the file/folder name. All tools used by LameXP should be Unicode-safe. But you can easily find out by renaming the AAC/MP4 file and trying again ;)

By the way: Can you share the "problematic" file via PM please?
I rename only the mp4 and work.... maybe too long path+name I think
mp sent

[LoRd_MuldeR]

The path you sent via PM is 192 characters long. That is much less than MAX_PATH, which is defined to 260. So that shouldn't be the problem.