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

[jpsdr]

I have a little question.
Even if the answer seems to be "no", i just want to be sure.
Is it possible to make 5.1 FLAC with LameXP ?

[LoRd_MuldeR]

Is it possible to make 5.1 FLAC with LameXP ?

Sure, why not?

LameXP is just a front-end, so if you feed it with a 5.1 source, it will send your 5.1 source to the FLAC encoder and thus create a 5.1 FLAC file.

http://pastie.org/private/07stkgg42uqf4vpy64ynfg
http://pastie.org/private/x5hwecovxsdo2mh8uq67ja

Actually what is not currently possible is creating a Stereo or Mono FLAC file from a 5.1 channel source...

[jpsdr]

... Ok. Interesting, but i'll ask differently, to precisely explain what i have i mind, because i think you're not telepath, and so can't guess...
Is it possible with LameXP to create a 5.1 FLAC file from 6 wav files ?
If yes, how ?
Before asking, i've just take a look at the 'user manual'... very interesting... ^_^
Not found any clue in the FAQ.

Edit :
If i understand the links you can feed directly .dts, interesting to know.
Is it possible also to feed directly .dtshd ?
(But i think in this cases eac3to can also do it...)

What i truly want to know, it's if i have to decode a DTSHD-MA or a THD file into wave files, edit these files (cuting or anything), having finaly 6 new wave files, is it possible to use LameXP to create a 5.1 FLAC file from these ?

[SeeMoreDigital]

Is it possible with LameXP to create a 5.1 FLAC file from 6 wav files ?In short, no!

But you can generate a 5.1Ch FLAC file from a 'single' 5.1(6)Ch PCM.wav file ;)

[LoRd_MuldeR]

Is it possible with LameXP to create a 5.1 FLAC file from 6 wav files ?

Nope. Currently each input file is considered a separate encoding job. So we have an 1:1 input file to output file mapping.

What i truly want to know, it's if i have to decode a DTSHD-MA or a THD file into wave files, edit these files (cuting or anything), having finaly 6 new wave files, is it possible to use LameXP to create a 5.1 FLAC file from these ?

Nope. You either need to process the DTS file directly or combine your 1ch Wave files to a single 6ch file before processing them with LameXP.

Is it possible also to feed directly .dtshd ?

Should be possible as long as MediaInfo can detect it and as long as Valdec (AC3Filter) can decompress it. Just give it a try ;)

[jpsdr]

Ok, thanks for your answers.

[LoRd_MuldeR]

LameXP v4.10 RC1:

Changes between v4.09 and v4.10 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-2
* Updated Qt runtime libraries to v4.8.6 (2014-04-25), compiled with MSVC 12.0
* Updated Opus libraries v1.1.x and Opus-Tools v0.1.8 to latest Git Master (2014-04-13)
* Updated MediaInfo to v0.7.69 (2014-04-26), compiled with ICL 14.0 and MSVC 12.0
* Updated mpg123 decoder to v1.19.0 (2014-03-08), compiled with GCC 4.8.2
* Fixed a bug that could cause the cover artwork to be lost under certain circumstances
* Added command-line options to adjust the LameXP font size (see FAQ doc for details)

If you find any showstopper bugs, then please report NOW ;)

[Motenai Yoda]

LoRd_MuldeR I notice now, but with Lame, on High Quality, q shouldn't be 2?
LameXP v4.09 (Build #1524), compiled on 2014-01-26 at 18:20:04

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

C:/Users/xxx/AppData/Local/Temp/a24c3764c4bbc8e6/lxp_flac.exe -d -F -f -o C:\Users\xxx\AppData\Local\Temp\a24c3764c4bbc8e6\c1440c995af24db9.wav "C:\xxx.flac"

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013 Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
done

Exited with code: 0x0000

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

C:/Users/xxx/AppData/Local/Temp/a24c3764c4bbc8e6/lxp_sox.exe --i C:/Users/xxx/AppData/Local/Temp/a24c3764c4bbc8e6/c1440c995af24db9.wav

Input File : 'C:/Users/xxx/AppData/Local/Temp/a24c3764c4bbc8e6/c1440c995af24db9.wav'
Channels : 2
Sample Rate : 44100
Precision : 16-bit
Duration : 00:04:35.48 = 12148668 samples = 20661 CDDA sectors
File Size : 48.6M
Bit Rate : 1.41M
Sample Encoding: 16-bit Signed Integer PCM

Exited with code: 0x0000

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

C:/Users/xxx/AppData/Local/Temp/a24c3764c4bbc8e6/lxp_lame.exe --nohist -q 3 --abr 128 C:\Users\xxx\AppData\Local\Temp\a24c3764c4bbc8e6\c1440c995af24db9.wav "C:\xxx.mp3"

LAME 3.99.5 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding C:\Users\xxx\AppData\Local\Temp\a24c3764c4bbc8e6\c1440c995af24db9.wav
to C:\xxx.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) average 128 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
Writing LAME Tag...done
ReplayGain: -7.9dB

Exited with code: 0x0000

[LoRd_MuldeR]

LoRd_MuldeR I notice now, but with Lame, on High Quality, q shouldn't be 2?

Nope. The LAME default is "-q3" now, which also is the default in LameXP, aka "High Quality".

The LAME CLI help seems to be a bit outdated here (it claims the default is "-q5"), but you can see the up-to-date documentation here:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#q

Especially note that with the "new" VBR mode, which is the default since LAME 0.98, there are only three quality "levels" anyway:

-q 0 to -q 4 include all features of the other modes and additionally use the best search when applying Huffman coding.
-q 5 and -q 6 include all features of -q7, calculate and consider actual quantisation noise, and additionally enable subblock gain.
-q 7 to -q 9 This level uses a psymodel but does not calculate quantisation noise when encoding: it takes a quick guess.

For example: You can easily check with MediaInfo that any setting in the "-q0" to "-q4" range will actually result in "-q0" ;)

[Motenai Yoda]

Nope. The LAME default is "-q3" now, which also is the default in LameXP, aka "High Quality".

The LAME CLI help seems to be a bit outdated here, but you can see the up-to-date documentation here:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#q
but -h still set -q 2


Especially note that with the "new" VBR mode, which is the default since LAME 0.98, there are only three quality "levels" anyway:
0.98 was relased years before this project began.

-q 0 to -q 4 include all features of the other modes and additionally use the best search when applying Huffman coding.
-q 5 and -q 6 include all features of -q7, calculate and consider actual quantisation noise, and additionally enable subblock gain.
-q 7 to -q 9 This level uses a psymodel but does not calculate quantisation noise when encoding: it takes a quick guess.

For example: You can easily check with MediaInfo that any setting in the "-q0" to "-q4" range will actually result in "-q0" ;)

MediaInfo says
Formato : MPEG Audio
Dimensione : 4,11MiB
Durata : 4min 35s
Modo bitrate generale : Variabile
Bitrate totale : 125 Kbps
Compressore : LAME3.99r

Audio
Formato : MPEG Audio
Versione formato : Version 1
Profilo formato : Layer 3
Modo : Joint stereo
Estensione modo : MS Stereo
Durata : 4min 35s
Modalità bitrate : Variabile
Bitrate : 128 Kbps
Canali : 2 canali
Frequenza campionamento : 44,1 KHz
Modo compressione : Con perdita
Dimensione della traccia : 4,11MiB (100%)
Compressore : LAME3.99r
Impostazioni compressione : -m j -V 4 -q 3 -lowpass 17 --abr 128
so for abr, cbr, and vbr_old q is the same as ever?

[LoRd_MuldeR]

but -h still set -q 2

Yes, I think so. Even though, to my understanding, setting "-q2" makes zero difference compared to the default.

At least for (new) VBR mode - which is what most users should be using most of the time.

Furthermore, since the default is "-q3" for all RC modes in current LAME, the default value in LameXP is consistent with LAME's default.

0.98 was relased years before this project began.

:confused:

AFAIK, LAME v3.98 was released on July 4 2008 (changelog (http://www.videohelp.com/tools/Lame-MP3/version-history)), while the first version of LameXP was released around 2004 (and used something like LAME v3.93).

Also I'm not quite sure how this is releated...

so for abr, cbr, and vbr_old q is the same as ever?

Yes, just as described in the documentation:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#q

(Note that there are two separate tables)

[Motenai Yoda]

:confused:

AFAIK, LAME v3.98 was released on July 4 2008 (changelog (http://www.videohelp.com/tools/Lame-MP3/version-history)), while the first version of LameXP was released around 2004 (and used something like LAME v3.93).

Also I'm not quite sure how this is releated...


1- I'm an idiot.
2- why all this time only with the latest versions there was this change?


Yes, just as described in the documentation:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#q

(Note that there are two separate tables)
Those docs is somewhat ambiguous, for vbr_new table depict the various levels, but the table for other modes only describes the various degrees of q, but it's the same q as 3.97 and older...

but if -q 2 doesn't change anything for vbr_new, but does and is still recommended for the other modes, why not set -q 2 instead of -q 3 with high quality? :confused:

[LoRd_MuldeR]

2- why all this time only with the latest versions there was this change?

Well, because originally the LameXP code had been written following LAME's command-line help:

-q <arg> <arg> = 0...9. Default -q 5
-q 0: Highest quality, very slow
-q 9: Poor quality, but fast
-h Same as -q 2. Recommended.
-f Same as -q 7. Fast, ok quality

So, at some point in LAME history, LAME's default apparently was "-q5", though the developers recommended using "-q2" (aka "-h").

Consequently, back at that time, making "-q5" the default of LameXP didn't seem like a good idea, even though it was LAME's default. Therefore, I decided to have a "-q2" setting and make that the default (as recommended).

However when I revisited the LameXP code (and studied the LAME documentation) later, I noticed that the LAME command-line help is actually outdated!

Current LAME versions use "-q3" as default. And they make no difference between "-q0" and "-q4" for the default (new) VBR mode anyway. Hence I decided to make LameXP more consistent with up-to-date LAME.


Those docs is somewhat ambiguous, for vbr_new table depict the various levels, but the table for other modes only describes the various degrees of q, but it's the same q as 3.97 and older...

I think the tables are quite clear. One is for everything except "new" VBR (which includes CBR, ABR and "old" VBR), and one is exclusively for "new" VBR.

(Yes, the table for the "old" modes also summarizes several values in a single row. But from the description it's clear they are not the same, e.g. "decreasing precision of parameters the further from -q 0")


but if -q 2 doesn't change anything for vbr_new, but does and is still recommended for the other modes, why not set -q 2 instead of -q 3 with high quality? :confused:

Well, because "-q3" is LAME's default. And so I though that it might be a good idea to make LameXP's default consistent with LAME's default as well as the LAME documentation.

Also I certainly do not want to expose all the possible "-q" values in LameXP - especially because most of these values are actually the same with "new" VBR.

Consequently, I decided to break it down to only four distinct "quality" modes in LameXP: 0 (when speed doesn't matter), 3 (the LAME default setting), 7 (fast setting with "okay" quality) and 9 (when only speed matters).

This decision isn't fixed. But, up to now, nobody has ever complained or made a better suggestion ;)

BTW: You are right that for the "new" VBR mode it doesn't matter whether we use "-q3" or "-q2", but for the other modes I wanted "-q3" to be the default. And if we have "-q3" already, I didn't want to have "-q2" too :eek:

[porcupene]

Maybe this needs to be addressed.

I'm doing flac to flac conversion. If I choose "Overwrite existing files" in the advanced options I get an error for each file, the originals are deleted and no files are converted. I just lose the original files. :confused:
This does not happen if I chose to save the converted files to a different folder. It seems the program first deletes the originals and then it tries to convert files that are no longer there.
It happens every time.



Version 4.09 final
Win7 64

[LoRd_MuldeR]

Maybe this needs to be addressed.

I'm doing flac to flac conversion. If I choose "Overwrite existing files" in the advanced options I get an error for each file, the originals are deleted and no files are converted. I just lose the original files. :confused:
This does not happen if I chose to save the converted files to a different folder. It seems the program first deletes the originals and then it tries to convert files that are no longer there.
It happens every time.



Version 4.09 final
Win7 64

Hi, porcupene.

If you run LameXP in "overwrite existing files" mode and the output file actually does exist already, then LameXP will try to delete that file. If successful, the output file can be saved to the location of the old/deleted file. Otherwise it can't. Now, if the file was successfully deleted, but the subsequent conversion fails, there won't be any file left, obviously. But the actual important question here is why your conversion has failed. So please post your log file...

[porcupene]

Here follows the error output:

LameXP v4.09 (Build #1524), compiled on 2014-01-26 at 18:20:04

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

Target output file already exists, going to delete existing file:
M:\BMF\1.flac

C:/Users/balaban/AppData/Local/Temp/c900e9a58ccecfa7/lxp_flac.exe -d -F -f -o C:\Users\balaban\AppData\Local\Temp\c900e9a58ccecfa7\a40358720d579be0.wav M:\BMF\1.flac

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013 Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
1.flac: ERROR while decoding metadata
state = FLAC__STREAM_DECODER_END_OF_STREAM

Exited with code: 0x0001

And for comparison the OK output for the same file once I switch to saving to a different folder.

LameXP v4.09 (Build #1524), compiled on 2014-01-26 at 18:20:04

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

C:/Users/balaban/AppData/Local/Temp/c900e9a58ccecfa7/lxp_flac.exe -d -F -f -o C:\Users\balaban\AppData\Local\Temp\c900e9a58ccecfa7\065b18cc3f56ed67.wav M:\BMF\1.flac

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013 Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
done

Exited with code: 0x0000

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

C:/Users/balaban/AppData/Local/Temp/c900e9a58ccecfa7/lxp_sox.exe --i C:/Users/balaban/AppData/Local/Temp/c900e9a58ccecfa7/065b18cc3f56ed67.wav

Input File : 'C:/Users/balaban/AppData/Local/Temp/c900e9a58ccecfa7/065b18cc3f56ed67.wav'
Channels : 2
Sample Rate : 44100
Precision : 16-bit
Duration : 00:05:33.69 = 14715876 samples = 25027 CDDA sectors
File Size : 58.9M
Bit Rate : 1.41M
Sample Encoding: 16-bit Signed Integer PCM

Exited with code: 0x0000

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

C:/Users/balaban/AppData/Local/Temp/c900e9a58ccecfa7/lxp_flac.exe -8 --channel-map=none -T "xxxxxxxxxxxxxxxx" -T "artist=xxxxxxxxxxxxxx" -T "album=xxxxxxxxxxxxxxx" -T genre=Vocal -T "comment=Encoded with LameXP" -T date=1995 -T track=1 -f -o M:\BMF\BMA\1.flac C:\Users\balaban\AppData\Local\Temp\c900e9a58ccecfa7\065b18cc3f56ed67.wav

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013 Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
wrote 32676327 bytes, ratio=0.555

Exited with code: 0x0000

So does it delete the flac before converting to a temporary wav file?

[LoRd_MuldeR]

Here follows the error output:

C:/Users/balaban/AppData/Local/Temp/c900e9a58ccecfa7/lxp_flac.exe -d -F -f -o C:\Users\balaban\AppData\Local\Temp\c900e9a58ccecfa7\a40358720d579be0.wav M:\BMF\1.flac
[...]
1.flac: ERROR while decoding metadata
state = FLAC__STREAM_DECODER_END_OF_STREAM
Exited with code: 0x0001C:/Users/balaban/AppData/Local/Temp/c900e9a58ccecfa7/lxp_flac.exe -d -F -f -o C:\Users\balaban\AppData\Local\Temp\c900e9a58ccecfa7\065b18cc3f56ed67.wav M:\BMF\1.flac
[...]
Exited with code: 0x0000

So your first log clearly shows that FLAC failed in the decoding step. This indicates that you have a broken/unsupported input FLAC file.

Note that the target output file (and therefore the "overwrite" mode) does not effect this step at all! That's because the job didn't even get to the encoding step!

Strangely, in your second log, the 100% identical command has succeeded, apparently. So the input FLAC file must have changed in the meantime...

(Either that, or the phase of the moon :p)


So does it delete the flac before converting to a temporary wav file?

Yes. Even before the encoding job is started.

Be aware that the input and output file are parameters of the encoding job, (passed in the constructor. So they are determined at the moment when the new job is about to be created.

In order to "overwrite", we must delete the existing file first. If, and only if, that succeeded, we can use the (no longer) existing file's path as the output file for the new job.

[foxyshadis]

The reason the second succeeded is because a wav file exists, but it's just a header with zero data. A new empty flac file may or may not exist, either way it signaled some sort of spurious success. That's computers for you. The only way to check would be to decode both and ensure they're the same length, which LameXp never does.

Overall, overwriting the original files seems more dangerous than it's worth. Don't do it unless you're so space limited that you have no choice. (Might be a good idea to call this out as dangerous in the UI, most people won't realize that.)

[LoRd_MuldeR]

The reason the second succeeded is because a wav file exists, but it's just a header with zero data. A new empty flac file may or may not exist, either way it signaled some sort of spurious success.

Huh? :confused:

Note that each conversion job consists of (at least) two phases: The decoding phase and the encoding phase. We are talking about the decoding phase here. In this phase, LameXP will decode the original input file (a FLAC file in this case) to a temporary WAV file. This temporary WAV file will never exist before. LameXP generates a random file name in its TEMP directory for this purpose and even makes sure the file really does not exist yet. The "overwrite existing file" option has absolutely no effect in this phase! It does have an effect only on the final encoding phase (where LameXP encodes from the temporary WAV to the target output file), but we didn't even get to this point, in the case where the job failed.

And indeed, if you look at his two logs (https://forum.doom9.org/showpost.php?p=1682057&postcount=1019), you'll notice that both logs start with the exactly same FLAC decoding command (except for the randomly generated TEMP file name, of course). The "strange" thing is that the identical command has failed in his first log, but apparently has succeeded in the second log. In the first log, FLAC rejected his input file. In the second log it didn't. This can only mean the original input FLAC file has changed in the meantime. Either that, or FLAC has some strange bug that triggers depending on the phase of moon. Or some buggy anti-virus software has interfered with FLAC (wouldn't be the first time). But it's impossible to say from here...

(Just to make it clear: The "overwrite existing file" option does not touch the original input file at all. Instead, it overwrites the target output file, if such file happens to already exist in the selected output directory)

Overall, overwriting the original files seems more dangerous than it's worth. Don't do it unless you're so space limited that you have no choice.

I perfectly agree with you. But the "overwrite existing file" option has been requested by users. It's not enabled by default. And there's a fat warning, when you select this option.

[porcupene]

Ok...

First ... if I'm annoying anyone with my silly error I'll stop :D

If not, here goes:

I use AVG and I disabled it temporarily, nothing changed.

It turns out it's not only FLAC but it happens also with mp3 and ogg (I suspect all the other encoders too). I know it's pointless to convert mp3 to mp3 but I just wanted to check the functionality.

So if I choose to save the files in the same folder and "Overwrite existing files" and do mp3 to mp3 or ogg to ogg conversion this happens:

LameXP v4.09 (Build #1524), compiled on 2014-01-26 at 18:20:04

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

Target output file already exists, going to delete existing file:
M:\BMF\1.mp3

C:/Users/balaban/AppData/Local/Temp/af3619121cd06397/lxp_lame.exe --nohist -q 0 -V 0 -m s M:\BMF\1.mp3 M:\BMF\1.mp3

Input file and Output file are the same. Abort.

Exited with code: 0xFFFFFFFF

or for ogg:

LameXP v4.09 (Build #1524), compiled on 2014-01-26 at 18:20:04

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

Target output file already exists, going to delete existing file:
M:\BMF\2.ogg

C:/Users/balaban/AppData/Local/Temp/af3619121cd06397/lxp_oggdec.exe -w C:\Users\balaban\AppData\Local\Temp\af3619121cd06397\fc2d59288aef2cda.wav M:\BMF\2.ogg

OggDec v1.9.7 (libVorbis 1.3.2), Compiled on: Dec 27 2010
Input M:\BMF\2.ogg does not appear to be an Ogg bitstream.
********** Done decoding all input files. **********

Exited with code: 0x0000

And here is the ok output once I choose to save to a different folder:

LameXP v4.09 (Build #1524), compiled on 2014-01-26 at 18:20:04

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

C:/Users/balaban/AppData/Local/Temp/af3619121cd06397/lxp_lame.exe --nohist -q 0 -V 0 -m s M:\BMF\1.mp3 M:\BMF\BMA\1.mp3

LAME 3.99.5 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
polyphase lowpass filter disabled
Encoding M:\BMF\1.mp3 to M:\BMF\BMA\1.mp3
Encoding as 44.1 kHz stereo MPEG-1 Layer III VBR(q=0)
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
Writing LAME Tag...done
ReplayGain: -4.3dB

Exited with code: 0x0000


and for ogg:

LameXP v4.09 (Build #1524), compiled on 2014-01-26 at 18:20:04

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

C:/Users/balaban/AppData/Local/Temp/af3619121cd06397/lxp_oggdec.exe -w C:\Users\balaban\AppData\Local\Temp\af3619121cd06397\1190288fb69d1bc3.wav M:\BMF\2.ogg

OggDec v1.9.7 (libVorbis 1.3.2), Compiled on: Dec 27 2010
Encoder Version: 0
Serial Number: 18706
Bitstream is 2 channel, 44100Hz
Scale = 1.0000
Decoded length: 14004984 samples = 5:17 mins.
Encoded by: AO; aoTuV [20110424] (based on Xiph.Org's libVorbis)
Decoding: M:\BMF\2.ogg
********** Done decoding all input files. **********

Exited with code: 0x0000

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

C:/Users/balaban/AppData/Local/Temp/af3619121cd06397/lxp_oggenc2.exe -q 9 -o M:\BMF\BMA\2.ogg C:\Users\balaban\AppData\Local\Temp\af3619121cd06397\1190288fb69d1bc3.wav

Opening with wav module: WAV file reader
Encoding "C:\Users\balaban\AppData\Local\Temp\af3619121cd06397\1190288fb69d1bc3.wav" to
"M:\BMF\BMA\2.ogg"
at quality 9.00
Done encoding file "M:\BMF\BMA\2.ogg"
File length: 5m 17.0s
Elapsed time: 0m 08.0s
Rate: 39.6967
Average bitrate: 329.9 kb/s

Exited with code: 0x0000


I did read the warning the program gives if I choose "Overwrite existing files" but is says I will loose the original file not both :(

Far be it from me to criticize this great program which I have used a long time but could it not just first save the wav file to a temporary folder and then and only then check if the target file already exists so it can safely be deleted?

[LoRd_MuldeR]

Target output file already exists, going to delete existing file:
M:\BMF\1.mp3

C:/Users/balaban/AppData/Local/Temp/af3619121cd06397/lxp_lame.exe --nohist -q 0 -V 0 -m s M:\BMF\1.mp3 M:\BMF\1.mp3

Input file and Output file are the same. Abort.

porcupene,

I think I now I understand what is going here! You not only selected the "overwrite existing file" mode, but you also made the output directory the same the input directory.

That plus the fact, that your are converting to the same audio format as the input files are, results the in weird situation that the input and output files (paths) for this job are one and the same! :eek:

This makes LameXP detect that the target output file already exists (which is correct) and thus delete that file (as desired by the user). Only that it's actually also the input file!

Now, one could argue that this is simply a usage error, because the user is requesting the impossible. Nonetheless I will try to implement a workaround to detect and deal with this situation...

[mike20021969]

If you find any showstopper bugs, then please report NOW ;)

10 days have passed... it must be close now :)

[LoRd_MuldeR]

10 days have passed... it must be close now :)

As long as people continue nagging me with their strange problems, it won't happen soon ;)

[porcupene]

porcupene,

I think I now I understand what is going here! You not only selected the "overwrite existing file" mode, but you also made the output directory the same the input directory.

I'm sorry I wasn't more clear. That's exactly what I'm doing.

I was just trying to replace in the same folder some flacs that had been encoded with "--compression-level-6" (or lower) with flacs that would be encoded with "--compression-level-8". I would normally end up with double the number of files and had to rename the new ones (because they would get a (2) in their name and manually delete the old ones) but then I stumbled upon the owerwrite option and said to myself: "Hey the program can do the renaming/deleting for me!"

You know the rest :)

[LoRd_MuldeR]

I'm sorry I wasn't more clear. That's exactly what I'm doing.

I was just trying to replace in the same folder some flacs that had been encoded with "--compression-level-6" (or lower) with flacs that would be encoded with "--compression-level-8". I would normally end up with double the number of files and had to rename the new ones (because they would get a (2) in their name and manually delete the old ones) but then I stumbled upon the owerwrite option and said to myself: "Hey the program can do the renaming/deleting for me!"

You know the rest :)

Yeah, I see. But the input and output file necessarily need to be two distinct files. The new code should make sure we won't delete the original input file.

Please try with this version:
http://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-RC1.2014-05-29.Release-Static.Build-1552.exe/download

[SeeMoreDigital]

Out of interest...

When generating FLAC encodes, would it be possible to add the 'Compression Level' (encoding settings) information to the files meta-data by default? In the same way this information is automatically added when generating APE encodes ;)


Cheers

[LoRd_MuldeR]

Out of interest...

When generating FLAC encodes, would it be possible to add the 'Compression Level' (encoding settings) information to the files meta-data by default? In the same way this information is automatically added when generating APE encodes ;)

That's probably more a question for the FLAC developers. But from what I can tell, MediaInfo does not report such info for my FLAC files.

(Either because the 'compression level' is not stored in the FLAC file or MediaInfo doesn't reveal it. In either case, the required changes are beyond my power)

[SeeMoreDigital]

...But from what I can tell, MediaInfo does not report such info for my FLAC files.Bummer...

A couple of weeks ago when I was trying to isolate some APE file playback issues with the Oppo hardware player, it was really useful knowing what APE 'Encoding settings' were used.

Having the same facility for Flac files would be even more useful, given their much greater appeal.

I wonder if the Flac developers would be interested in adding the info...

[porcupene]

It sort of works now, see the messages.

[LoRd_MuldeR]

LameXP v4.10 RC2:

Changes between v4.09 and v4.10 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-2
* Updated Qt runtime libraries to v4.8.6 (2014-04-25), compiled with MSVC 12.0
* Updated Opus libraries v1.1.x and Opus-Tools v0.1.8 to latest Git Master (2014-04-13)
* Updated MediaInfo to v0.7.69 (2014-04-26), compiled with ICL 14.0 and MSVC 12.0
* Updated mpg123 decoder to v1.19.0 (2014-03-08), compiled with GCC 4.8.2
* Fixed a bug that could cause the cover artwork to be lost under certain circumstances
* Fixed "overwrite existing file" mode to NOT delete the input file
* Some more tweaks to the LAME algorithm quality selector
* Added command-line options to adjust the LameXP font size (see FAQ doc for details)
* Various bugfixes and code improvements

If you find any showstopper bugs, then please report NOW ;)

[Jeroi]

Have to give you a Rep, pretty fast encoding and using all my threads but no hyperthreading support. Please add that then I can have 8 threads instead 4. Also the path chooser is bit tedious, could you please give a option to make exact copy of the folder to the output folder? Ie If I want to copy folder and make 128kbit I want evertyhing in the folder and files encoded with 128kbit. Now I needed to make my own folders and browse to the folder with the chooser, and album art's were not copied...

[LoRd_MuldeR]

Have to give you a Rep, pretty fast encoding and using all my threads but no hyperthreading support.

Actually there is no such thing "hyperthreading support".

With hyperthreading, there simply are twice the number of ("logical") CPU cores visible to the operating system than there are "physical" CPU cores. This allows for scheduling two threads per "physical" CPU core. The reasoning is that often a single thread doesn't fully utilize all the execution units of the CPU core. So by scheduling two threads on a single "physical" CPU core, these threads will share the available execution units, which can increase the utilization of these execution units and give a (small) overall speed-up. The only thing that an application must do in order to "support" hyperthreading is distributing the calculations among a sufficiently large number of threads - which may or may not be possible/reasonable.

(There even are some highly optimized applications, such as Linpack, where hyperthreading is harmful)

Please add that then I can have 8 threads instead 4.

LameXP doesn't implement "multi-threading" on a per-thread basis, but by running multiple encoder instances (encoding jobs) in parallel. LameXP actually has zero control over how many threads a particular encoder (or decoder) will create. Anyway, the number of instances that will be run in parallel by default is inferred from the number of CPU cores. However, simply running one instance per CPU core is not a very good idea! On systems with a very large number CPU's this could easily result in HDD thrashing and actually slow-down the overall process. So we use some heuristic function that looks like this (http://i.imgur.com/QbS47Wi.png). In any case, you can manually set the number of parallel instances on the "Advanced Options", if you which to experiment.

Also the path chooser is bit tedious, could you please give a option to make exact copy of the folder to the output folder? Ie If I want to copy folder and make 128kbit I want evertyhing in the folder and files encoded with 128kbit. Now I needed to make my own folders and browse to the folder with the chooser, and album art's were not copied...

LameXP will process all files that you have added to the "Source Files" tab and it will store the re-encoded files in the selected output directory. It certainly does not touch any unrelated files. Copying all (unrelated) files from all input directories, i.e. all directories from which the user has added at least one input file, into the output directory doesn't seem reasonable to me - even if we make it optional.

[mariush]

Maybe add a separate option "Replace original file with the new encoded file" and maybe add a sub-option "Append ' - old version' to the file name of original file, instead of deleting it" or "Move original files to this folder : " ...

This way user can choose if he/she wants to risk losing the original file or not, let's say if he's paranoid and wants to double check if the new file is compressed correctly or not.

[LoRd_MuldeR]

Maybe add a separate option "Replace original file with the new encoded file" and maybe add a sub-option "Append ' - old version' to the file name of original file, instead of deleting it" or "Move original files to this folder : " ...

This way user can choose if he/she wants to risk losing the original file or not, let's say if he's paranoid and wants to double check if the new file is compressed correctly or not.

That sounds like a reasonable solution, though it's somewhat orthogonal to the current scheme of "select output directory" + "choose how to deal with existing files".

[LoRd_MuldeR]

http://www.smileysnetwork.com/malade/malade11.gif

Just to let you know: Things have been delayed because I have been sick with the flu. Spent most of the past week in bed.

Things are back to normal now, but a lot of work has accumulated over the week, which I need to take care of first. So further delay is to be expected...

[boyumeow]

Please Take Good Care of Yourself, Flu nowadays has became different, and should not be taken lightly. Thanks and take care a lot.

[LoRd_MuldeR]

LameXP v4.10 has been released :)
https://github.com/lordmulder/LameXP/releases/latest

Changes between v4.09 and v4.10 [2014-06-23]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-2
* Updated Qt runtime libraries to v4.8.6 (2014-04-25), compiled with MSVC 12.0
* Updated Opus libraries v1.1.x and Opus-Tools v0.1.8 to latest Git Master (2014-04-13)
* Updated MediaInfo to v0.7.69 (2014-04-26), compiled with ICL 14.0 and MSVC 12.0
* Updated mpg123 decoder to v1.19.0 (2014-03-08), compiled with GCC 4.8.2
* Fixed a bug that could cause the cover artwork to be lost under certain circumstances
* Fixed "overwrite existing file" mode to NOT delete the input file
* Some more tweaks to the LAME algorithm quality selector
* Added command-line options to adjust the LameXP font size (see FAQ doc for details)
* Various bugfixes and code improvements

[Przemek_Sperling]

Thank you! :)

[LoRd_MuldeR]

LameXP v4.11 Alpha-1
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2014-06-27/

Changes between v4.10 and v4.11 [unreleased]:
* Updated mpg123 decoder to v1.20.1 (2014-06-17), compiled with GCC 4.9.0
* Updated Vorbis encoder to OggEnc v2.87 (2014-06-24), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2014-06-25), using libVorbis v1.3.4

[davexnet]

I'm curious what switches it sends to the Lame encoder. I set it up to use Version 3.98.4 -
any issue there in terms of the generated switches and compatibility ?

My mp3 came out to be 5.39 MB. using compression/QL2 (default) and Advanced Option/High Quality (default).

However, when I executed Lame from the command line using the same WAV file, I get an mp3 of 5.44 MB.
Why the discrepancy ? Here's my command line:
lame.exe -h -V 2 samp8.wav samp8_cmd_v2qh.mp3

[LoRd_MuldeR]

I'm curious what switches it sends to the Lame encoder.

You can see the full command-line generated by LameXP in the log. Or just inspect the LAME process with a proper taskmanager (http://technet.microsoft.com/de-de/sysinternals/bb896653.aspx).

I set it up to use Version 3.98.4 - any issue there in terms of the generated switches and compatibility ?

Probably not.

But I don't test explicitly with old LAME versions (especially not with one that is more than 4 years old), only with the up-to-date one that is included in LameXP. So, no guarantees ;)

Any particular reason why you want to use such an outdated LAME version?

My mp3 came out to be 5.39 MB. using compression/QL2 (default) and Advanced Option/High Quality (default).

However, when I executed Lame from the command line using the same WAV file, I get an mp3 of 5.44 MB.
Why the discrepancy ? Here's my command line:
lame.exe -h -V 2 samp8.wav samp8_cmd_v2qh.mp3

Don't know. Selecting "High Quality (default)" will set the "-q2" switch. And since "-h" is simply an alias for "-q2", there should be no difference - given you also selected the same VBR level.

But you may wish to actually compare the command-lines in order to make sure you hadn't set any extra options in LameXP...

[davexnet]

You can see the full command-line generated by LameXP in the log. Or just inspect the LAME process with a proper taskmanager (http://technet.microsoft.com/de-de/sysinternals/bb896653.aspx).



Probably not.

But I don't test explicitly with old LAME versions (especially not with one that is more than 4 years old), only with the up-to-date one that is included in LameXP. So, no guarantees ;)

Any particular reason why you want to use such an outdated LAME version?



Don't know. Selecting "High Quality (default)" will set the "-q2" switch. And since "-h" is simply an alias for "-q2", there should be no difference - given you also selected the same VBR level.

But you may wish to actually compare the command-lines in order to make sure you hadn't set any extra options in LameXP...


I think I got mixed up with something else. LameXP is using it's own internal Lame mp3 encoder?
I see that it copies a bunch of files to a sub-folder in the temp directory. The version that is there is 3.99 release 5, 469KB.

Version 3.98.4 was the version I was testing and comparing the result using the CMD prompt.
I assume it's not possible to override the version LameXP is using?

3.98.4 was a bit of a cult version, in terms of sound quality, many seem to prefer to more recent versions.
I did a test of 3.99.5 in foobar2000 compared to 3.98.4 and the newer version sounded poor in comparison.
(although once again, I'm not sure what arguments are being passed to the encoder)

At least in the LameXP log, I can see what its doing. Thanks for that tip.

[LoRd_MuldeR]

I think I got mixed up with something else. LameXP is using it's own internal Lame mp3 encoder?

Yes, it does ship with its own LAME encoder binary. It's a fully self-container application.

I see that it copies a bunch of files to a sub-folder in the temp directory. The version that is there is 3.99 release 5, 469KB.

Exactly. But you can also see the "third-party software" section in the About screen for list of tools included...

Version 3.98.4 was the version I was testing and comparing the result using the CMD prompt.

So if you were actually using two different LAME versions, it's clear why results don't match.

I assume it's not possible to override the version LameXP is using?

It is! See the documentation:
http://lamexp.sourceforge.net/doc/FAQ.html#3d6684e9

3.98.4 was a bit of a cult version, in terms of sound quality, many seem to prefer to more recent versions.

Is there any serious listening test that substantiates this theory?

[davexnet]

Yes, it does ship with its own LAME encoder binary. It's a fully self-container application.



Exactly. But you can also see the "third-party software" section in the About screen for list of tools included...



So if you were actually using two different LAME versions, it's clear why results don't match.



It is! See the documentation:
http://lamexp.sourceforge.net/doc/FAQ.html#3d6684e9



Is there any serious listening test that substantiates this theory?

If you peruse the www.hydrogenaud.io forums, there's plenty of discussion, but no consensus. Lots of talk about whether the result
is "transparent" (What ever that means). I think some of it depends on the material; This afternoon I took 5 or 6 uncompressed WAV files of
different kinds of music and encoded some mp3's at the command line using 3.98.4 and 3.99.5 using v1, v2 & v5 all with the -h switch.

To me neither of them sounds like the WAV file. The uncompressed music just has more "presence" that the mp3's aren't quite able
to reach. I can hear in some of the samples that v1 sounds better than v2. The point is, for playing in the car,
even a playlist on your favorite media player over the computer speakers, the default settings are mostly good enough.
HD audio sounds better than CD @ 44.1 khZ 16 bits, but does that mean you can never enjoy your CD's again,
because in the back of your mind you know there's something better. I hope not!

Some music sounds better on vinyl. The one that I notice the most is Carole Kings Tapestry. I even have an audio cassette
that was recorded on a hifi from vinyl that retains the warmth of the vinyl, and to my ears, sounds better than
the CD, even the remastered version from a few years ago.


I like your program, I'll use it as is, no need to substitute a different Lame. It's been some years since I used it,
so long I actually forgot about it. I maintain a folder for these "portable" apps, and right next to this one,
I was surprised to see Lame XP .2008 12-24 version 3.07. so it's been a while since I looked at it.

Thanks again.

[mike20021969]

"transparent" (What ever that means).

It means whether or not you can hear a difference between the original and converted file.

If you cannot hear a difference, it is transparent.

More here:
https://en.wikipedia.org/wiki/Transparency_%28data_compression%29

[davexnet]

It means whether or not you can hear a difference between the original and converted file.

If you cannot hear a difference, it is transparent.

More here:
https://en.wikipedia.org/wiki/Transparency_%28data_compression%29

Some people can't hear the difference between 128 and 320 kbps mp3. How is the "ear of the beholder"
taken into account? I know that when I converted some of my video to mpeg-2 DVD,
the audio (different types) was converted to ac3-2-channel. I found 256 kbps ac3 was at the point where this
kind of conversion sounded "transparent" - in contrast 224 kbps ac3 sounded a little "pinched".
But this is not music. It's a typical video, some voices, some environmental sounds, etc,etc.

I think what I'm trying to say is that when we listen to music we listen with a much more critical ear.
Especially when we convert them ourselves. Through my local library, they have a thing where you can download
5 free music tracks a week. I've downloaded some and so far I've seen 192 and 256 kbps mp3.
Not having a better source to immediately compare to, and the fact that they came from the library and were free,
gives me a psychological "freedom" to enjoy them as-is with out worrying about the sound quality.

[foxyshadis]

Some people can't hear the difference between 128 and 320 kbps mp3. How is the "ear of the beholder"
taken into account? I know that when I converted some of my video to mpeg-2 DVD,
the audio (different types) was converted to ac3-2-channel. I found 256 kbps ac3 was at the point where this
kind of conversion sounded "transparent" - in contrast 224 kbps ac3 sounded a little "pinched".
But this is not music. It's a typical video, some voices, some environmental sounds, etc,etc.

I think what I'm trying to say is that when we listen to music we listen with a much more critical ear.
Especially when we convert them ourselves. Through my local library, they have a thing where you can download
5 free music tracks a week. I've downloaded some and so far I've seen 192 and 256 kbps mp3.
Not having a better source to immediately compare to, and the fact that they came from the library and were free,
gives me a psychological "freedom" to enjoy them as-is with out worrying about the sound quality.

Transparent has two meanings: One person can't tell a difference between two versions, or the majority of trained people can't. (HA is quite a bit more elite than the general population.) Presets are based on the second meaning, but you should base your decision on the first meaning. If you happen to have golden ears or prefer an EQ that breaks psychoaudio assumptions, then what's stopping you from using more bits, or an older version, or FLAC/not re-encoding? No one will judge you, in fact, no one cares. It's your collection, do what makes sense to you.

[jfcarbel]

Happy 10th anniversary and thanks for LameXP and AVIDemux!

[LoRd_MuldeR]

LameXP v4.11 Alpha-2

Changes between v4.10 and v4.11 [unreleased]:
* Updated mpg123 decoder to v1.20.1 (2014-06-17), compiled with GCC 4.9.0
* Updated Vorbis encoder to OggEnc v2.87 (2014-06-24), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2014-06-25), using libVorbis v1.3.4
* Fixed potential crash in Cue Sheet importer (occurred when *all* input files were missing)

[LoRd_MuldeR]

LameXP v4.11 Alpha-3

Changes between v4.10 and v4.11 [unreleased]:
* Updated MediaInfo to v0.7.70 (2014-09-03), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus libraries to v1.1.x and Opus-Tools v0.1.9 to latest Git Master (2014-10-04)
* Updated mpg123 decoder to v1.20.1 (2014-06-17), compiled with GCC 4.9.0
* Updated Vorbis encoder to OggEnc v2.87 (2014-06-24), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2014-06-25), using libVorbis v1.3.4
* Fixed potential crash in Cue Sheet importer (occurred when *all* input files were missing)

[jpsdr]

I've been told, for 24 bits flac files encoded with LameXP, that the tag HDCD is not set. Is it possible to handle this ?

[LoRd_MuldeR]

I've been told, for 24 bits flac files encoded with LameXP, that the tag HDCD is not set. Is it possible to handle this ?

I have no idea what "the tag HDCD" is :confused:

Anyway, LameXP is just a fron-end and uses the official FLAC encoder by Xiph.org (currently version 1.3.0, which should be the latest). So, unless you think that LameXP is calling the FLAC encoder with the "wrong" arguments, that's probably something you'd have to discuss with the FLAC developers. And if you do think LameXP should be calling FLAC in a different way, then please be more specific. I cannot see anything related to "tag HDCD" in the FLAC help screen...

[jpsdr]

In that case, don't bother. I've made for someone mkv file with flac from 24 bits wave for audio, encoded with LameXP.
The feedback was :
- Encode is not clean, because there is "Encoded with LameXP" in the comment tag...:confused:
I've been stunned by this stupid comment ! :eek:
- The bit (or tag, don't know) HDCD is set to 0. 1 should had been better.
If it's something you don't know about, never mind.

[LoRd_MuldeR]

The feedback was :
- Encode is not clean, because there is "Encoded with LameXP" in the comment tag...:confused:

Yes, LameXP adds the comment as a meta tag, by default. But in what way is this "not clean", please? :confused:

If you don't like it, you can clear the comment field at any time or simply input your own comment text there. See the "Meta Data" tab.

Of course it also should be straight forward to edit or remove the meta tags of an existing FLAC file.

(Despite of its name, Mp3tag (http://www.mp3tag.de/en/) is capable of editing FLAC tags)

- The bit (or tag, don't know) HDCD is set to 0. 1 should had been better.
If it's something you don't know about, never mind.

I still have no idea what the purpose of that "HDCD" tag is.

And is FLAC supposed to add this automatically or is the front-end supposed to add it explicitly? In the latter case: Under what circumstances?

Well, at this point it's not even clear whether this so-called "HDCD tag" is a bit in the FLAC header or just a custom meta tag...

[jpsdr]

But in what way is this "not clean", please? :confused:

Maybe i was not clear enough. This was the feedback from the person for who i made the mkv.
As i've stated, i found this comment nonsense.
But thanks for the tips for removing it.

I personnaly use and will still use your tool, i found it very usefull.
Thank for it.

Edit :
Ok, a little more information from "the complainer" :
Encoded with LameXP :

General
Complete name : P:\MPEG-2\AoT-SP1.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 30.7 MiB
Duration : 6mn 44s
Overall bit rate mode : Variable
Overall bit rate : 637 Kbps
Track name : AoT-SP1
Comment : Encodé avec LameXP
track : 25

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 6mn 44s
Bit rate mode : Variable
Bit rate : 637 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 30.7 MiB (100%)
Writing library : libFLAC 1.3.0 (UTC 2013-05-26)


Encoded with eac3to :

General
Complete name : I:\Op-1.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 19.3 MiB
Duration : 1mn 31s
Overall bit rate mode : Variable
Overall bit rate : 1 765 Kbps
VALID_BITS : 24
HDCD : 0

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 1mn 31s
Bit rate mode : Variable
Bit rate : 1 765 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Stream size : 19.3 MiB (100%)
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)


Don't tested with Foobar2000.

[LoRd_MuldeR]

Can't reproduce :confused:

Input:
http://i.imgur.com/adHjQi7.png

Conversion Log:
LameXP v4.11 (Build #1577), compiled on 2014-10-10 at 15:39:16

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

C:/Users/MuldeR/AppData/Local/Temp/ecaabf31b42a09a6/lxp_sox.exe --i E:\Samples\Audio\Uncompressed_44khz_24.wav

Input File : 'E:\Samples\Audio\Uncompressed_44khz_24.wav'
Channels : 2
Sample Rate : 44100
Precision : 24-bit
Duration : 00:03:16.16 = 8650752 samples = 14712.2 CDDA sectors
File Size : 51.9M
Bit Rate : 2.12M
Sample Encoding: 24-bit Signed Integer PCM

Exited with code: 0x0000

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

C:/Users/MuldeR/AppData/Local/Temp/ecaabf31b42a09a6/lxp_flac.exe -8 --channel-map=none -T "title=Uncompressed 44khz 24" -T "comment=Kodiert mit LameXP" -T track=1 -f -o C:\Users\MuldeR\Music\Uncompressed_44khz_24.flac E:\Samples\Audio\Uncompressed_44khz_24.wav

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013 Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
Uncompressed_44khz_24.wav: WARNING: skipping unknown chunk 'fact' (use --keep-foreign-metadata to keep)
wrote 21987923 bytes, ratio=0,424

Exited with code: 0x0000

Output:
http://i.imgur.com/0crca8Q.png

[jpsdr]

In that case, maybe eac3to add something more on his own on the flac header, not added by flac.exe, but still compliant to flac standard/header...?

[SeeMoreDigital]

jpsdr,

Out of interest, what application was used to back-up the HDCD?

I'm not aware of any audio CD back-up application that's able to make use of the HDCD flag even when creating PCM file back-up's!

[jpsdr]

Absolutely none, it's just a 24 bit audio wave file extracted from a Blu-Ray m2ts. It's not from CD audio, and i don't know any application able to do it, and i didn't even know about HDCD 2 days ago...
I was just complained to about the fact i described, and so warned that LameXP may be less reliable because unable to handle this feature, but eac3to can... It seems that "this HDCD" may be used on other files/tracks than on CD. I don't know, and don't want to bother Lord Mulder too much if he also doesn't know about it.

[foxyshadis]

HDCD is modern ADPCM: Give more bits to soft sounds and less to loud sounds. The HDCD tag just tells the player (only dbPowerAmp understands it) to uncompress it back in 24bit when playing, otherwise it sounds much too loud. Your friend is definitely spouting nonsense if he wants the tag added, but he can add it himself if he wants, it's just a plain old tag.

[jpsdr]

Do you know, by any luck, on what kind of file you can find this tag, others than flac ?

[SeeMoreDigital]

Do you know, by any luck, on what kind of file you can find this tag, others than flac ?Perhaps you (and your friends) should obtain some actual HDCD disc's to determine the differences between a regular audio CD and an HDCD before moving onto the subject of audio encoders making use of the HDCD flag...

As for generating 24-bit Flac files from "24-bit audio wave file extracted from a Blu-Ray .m2ts" files. LameXP does not have any problems handling/encoding these. And given such content does not contain any HDCD data, the 24-bit Flac encode does not require any additional flagging!

It would seem somebody somewhere is getting themselves very confused. And spouting their confusion onto others!

[Groucho2004]

In that case, maybe eac3to add something more on his own on the flac header, not added by flac.exe, but still compliant to flac standard/header...?

Have a look at the eac3to change log, it's custom meta-data:
v2.67
* information about HDCD and real bitdepth is now stored into FLAC metadata

[jpsdr]

Ok, thanks for all these informations.

[SeeMoreDigital]

Hi LoRd_MuldeR,

I'm currently running an evaluation version of Windows 10 64-bit. Before LameXP starts up I see the following message: -

http://i61.tinypic.com/2lw6fbd.png

Just thought you'd like to know... It seems to be working okay :)

[LoRd_MuldeR]

Hi LoRd_MuldeR,

I'm currently running an evaluation version of Windows 10 64-bit. Before LameXP starts up I see the following message: -

http://i61.tinypic.com/2lw6fbd.png

Just thought you'd like to know... It seems to be working okay :)

See these commits, just a few hours ago:
* https://bitbucket.org/lord_mulder/lamexp/commits/add0de2472f9501fabb4f9bacbd82c0e0f94062f
* https://bitbucket.org/lord_mulder/lamexp/commits/0d583cd711ae1807b86d3c8e1d44bd8e7f0b886b

[SeeMoreDigital]

See these commits, just a few hours ago:
* https://bitbucket.org/lord_mulder/lamexp/commits/add0de2472f9501fabb4f9bacbd82c0e0f94062f
* https://bitbucket.org/lord_mulder/lamexp/commits/0d583cd711ae1807b86d3c8e1d44bd8e7f0b886bAmazing :)

[LoRd_MuldeR]

LameXP Test-Build r1598 :eek:

This is the first version after major refactoring of the LameXP codebase. Actually, that process is still in progress and will not be completed anytime soon. The reason is that, over the years, a lot of code had accumulated in the LameXP project that was not specific to LameXP at all. Even worse, a lot of that code is required in other projects (Simple x264 Launcher, MediaInfoXP, DoubleFileScanner, etc) too. So far, this had been handled in a "copy and past" fashion, which has lead to loads of redundant code. In the past few days I finally took the opportunity to refactor all the code in LameXP that is not specific to LameXP into a separate library. My goal is to use that library also in all the other projects, once it is complete.

If all went well so far, users should not notice a difference. Anyway, take this version with a grain of salt and please report any regressions you may notice...

[SeeMoreDigital]

Hello,

I've just tried running the new build using Win10 64-bit Build 9879. And I got this: -

http://i60.tinypic.com/2hp1469.jpg


What does it all mean? Cheers

[foxyshadis]

http://pldh.net/media/dreamworld/054.png

I'd double-check that all the files were extracted with folders, and barring that see if permissions don't deny anything; that would show up if the imageformats folder is missing or can't be read for some reason.

Mulder, I hate to say it, but I just put this on my new laptop for the first time, and this is one of the more unpleasant "first impressions" of a software I've ever used, up there with Autodesk or Adobe. Four popups in a row, two of which couldn't be clicked away without waiting a few seconds. If I didn't appreciate LameXP's usefulness, I'd immediately remove it.

Regarding AAC popup: I would make that happen when you click on the AAC format, no sooner, rather than greying it out. Actually I'd make it a big warning on the panel, not a pop-up, but sometimes you just have to get in someone's face.

Regarding updates: Holy hell, do that in the background. Reminds me of smplayer's obnoxious "no updates found!" popup every reboot.

Regarding translations: Is annoying thousands of people who can't contribute worth the hope that one might?

[SeeMoreDigital]

I'd double-check that all the files were extracted with folders, and barring that see if permissions don't deny anything; that would show up if the imageformats folder is missing or can't be read for some reason.

Everything looks to have extracted and the imageformats folder is present. And I tried copying the files within the imageformats folder and placing them within the main folder: -

http://i61.tinypic.com/2qa74mc.jpg

[lethedoom]

PROBLEM HAS RESOLVED

LameXP Test-Build r1598 is not available.

http://sourceforge.net/projects/lame...5.zip/download

leads to a dead download link or alternatively to

http://sourceforge.net/projects/lamexp/files/Snapshots%20(BETA)/

where 2014-10-05 is now the latest posting. I recall seeing a later file (11/17 ?) which is now gone.

Now it is even worse--basically offline.

The sourceforge.net website is temporarily in static offline mode.
Only a very limited set of project pages are available until the main website returns to service.

SF.net Operations @sfnet_ops
There's instability and frequent 500 errors on the SourceForge site currently. We're working on getting this fixed as soon as we can


LameXP Test-Build r1598 opened without problems and functioned as well as earlier versions. Thanks for your generosity.


I don't know what QAAC is about.Log images attached.

[mariush]

Latest Avira detects lxp_mpg123.exe as infected with TR/Crypt.XPACK.Gen ... lamexp (1582) crashes with an error "unable to lock file" or something like that.

I agree that the message box with forced delay of 8-10s is over the top.

[LoRd_MuldeR]

I've just tried running the new build using Win10 64-bit Build 9879. And I got this: -

What does it all mean? Cheers

First of all, it means that I have the message and the title interchanged in that error dialog box :p

Secondly, it means that Qt failed to load its Image I/O plug-in's for some reason :eek:

Actually I was able to reproduce this error on my Windows 10 Preview VM, while it works perfectly fine for me on my Windows XP VM as well as on my Windows 8.1 VM and on my "main" Windows 7 machine :confused:

Either this is some regression in the Preview of Windows 10 that they will fix (hopefully) before the RTM. Or they intentionally changed the DLL loading behavior in a way that breaks Qt's plug-ins :rolleyes:


Everything looks to have extracted and the imageformats folder is present. And I tried copying the files within the imageformats folder and placing them within the main folder

Image I/O plug-ins need to be in the "imageformats" sub-folder for Qt to recognize them:
http://i.imgur.com/HWrzPEP.jpg


Latest Avira detects lxp_mpg123.exe as infected with TR/Crypt.XPACK.Gen ... lamexp (1582) crashes with an error "unable to lock file" or something like that.

If you are an Avira user, you may wish to send a report to the Avira support, so they can fix the bug in their software. Otherwise, just ignore ;)

See also:
http://muldersoft.com/docs/lamexp_faq.html#96205e91


Mulder, I hate to say it, but I just put this on my new laptop for the first time, and this is one of the more unpleasant "first impressions" of a software I've ever used, up there with Autodesk or Adobe. Four popups in a row, two of which couldn't be clicked away without waiting a few seconds. If I didn't appreciate LameXP's usefulness, I'd immediately remove it.

Please note that this is a pre-release beta build and neither the "call for translators" notification nor the "debug console" window is present in regular release builds.

Also note that the notice about the missing AAC encoder will appear only if you haven't installed the Nero AAC encoder yet. Once the Nero AAC binary has been put into the correct place, you'll never see the notice again.

Reviewers even explicitly praise the notification, because "the task is not too difficult to carry out as everything is provided for the job: link to the download file, folder location and step by step instructions".

(Of course I'd prefer to have AAC encoder built-in too, but Nero AAC cannot be redistributed for legal reasons. QAAC isn't a practicable alternative here either, because it depends on the proprietary Apple/QuickTime DLL's)


Regarding updates: Holy hell, do that in the background. Reminds me of smplayer's obnoxious "no updates found!" popup every reboot.

Many users prefer if the application will not talk to external servers "behind the user's back". Obviously, you can't do it right for everybody.

(If with "smplayer" you are referring to my "MPlayer for Windows" package, then the included auto-updater does not check for updates on every reboot. It only does so once every 30 days)


I don't know what QAAC is about. Log images attached.

It means that the optional QAAC add-in is not currently present. If you want to use QAAC (instead of Nero AAC), you may download the required add-in from here (http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/).

[lethedoom]

Avast anti-virus stopped the test version from opening. The program then accepted assurance file was safe and could be excluded from scanning.I restored the sequestered files, deleted the record form the virus chest and then was able to open and use the test version. I was unable to satisfy the information requirements of the false positive submission form, so other Avast users may have the same problem.

[mariush]

The executable is compressed with UPX 3.91 (executable compressor), which is often used by "bad people" to reduce the executable size of viruses, trojans etc ... it's a good valid compressor, but a bad reputation due to the above mentioned things.

You could just unpack the executable (436,238 bytes uncompressed vs 169,998 bytes compressed) and you've solved the antivirus problem instead of just asking people to disable antivirus software or stop using lamexp until antivirus updates signature database (which could be 1-2 weeks).

[LoRd_MuldeR]

Hello,

I've just tried running the new build using Win10 64-bit Build 9879. And I got this:

http://i60.tinypic.com/2hp1469.jpg

Okay, I now know what caused the problem!

I compiled the program and the "core" Qt DLL's with the current VS2013.4, but for some reason I accidentally included the Qt Plug-in DLL's compiled with VS2010 :o

Mixing DLL's that are linked against different C-Runtimes is a bad idea anyway. But since the VS2010 Runtime DLL's weren't included in the package, the Plug-in DLL's didn't load at all.

(It will be fixed in the next build)

[LoRd_MuldeR]

LameXP Test-Build r1603 :eek:

New build after more refactoring work has been done. This time hopefully with the correct plug-in DLL's included ;)

[lethedoom]

I extracted the new test folder and scanned it with Avast which reported no threat. LameXP Test-Build r1603 opened without the debug console and successfully converted flac files to mp3. Is this a beta or an unlabelled 4.11 final ?

[SeeMoreDigital]

LameXP Test-Build r1603 :eek:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2014-11-29/LameXP-TEST.2014-11-29.zip/download

New build after more refactoring work has been done. This time hopefully with the correct plug-in DLL's included ;)I'm happy to confirm it's working a treat now with Win10 64-bit Build 9879 :)

[LoRd_MuldeR]

I extracted the new test folder and scanned it with Avast which reported no threat. LameXP Test-Build r1603 opened without the debug console and successfully converted flac files to mp3. Is this a beta or an unlabelled 4.11 final ?

This is far from anything "final" at this point, as the refactoring process is still going on ;)

I'm happy to confirm it's working a treat now with Win10 64-bit Build 9879 :)

Good to know!

[lethedoom]

Today Avast deemed the LameXP Test-Build r1603 application a virus and killed it. I tried to download the zip file again and it would not permit the download. I cannot satisfy their demand for information on their false positive form . It is not clear if 'Lord Mulder' as publisher or 'LameXP' as program is deemed not clear enough. I will try to let them know the problem.

I submitted the ticket and hope they respond favorably.If you contact them directly perhaps they can resolve the problem for future iterations.

Posted on: 29 November 2014 18:27
I downloaded from http://sourceforge.net/projects/lamexp/files/Snapshots (BETA)/ the LameXP-TEST.2014-11-29.zip
yesterday. I extracted the files and scanned both the zip and extracted files folders and avast found no threat. I opened the beta application and used it. This morning when I opened the same application Avast identified it as a virus and put it in the chest. I went to the chest and right clicked on the file and chose restore and add to exclusions. I attempted to fill out a false positive form but either 'Lord Mulder' or 'Source Forge' as publisher or 'LameXP' as program was deemed insufficiently informative and form refused to submit. This is a beta program distributed in a zip file which Avast on second thought has labelled Win32:Evo-gen {Susp}. I know what I am doing, I trust Lord Mulder even though he is too stubborn to change his zip program. Please check this folder from http://hivelocity.dl.sourceforge.net/project/lamexp/Snapshots (BETA)/2014-11-29/LameXP-TEST.2014-11-29.zip :

LameXP-TEST.2014-11-29.zip < 16 hours ago 21.4 MB 66 weekly downloads i
SHA1:

09c3216a2decb4f0c980026015b5e0f97c4cf842

MD5:

aac1af01da9ba2ddbc9a76cf699ae70e

Downloads (All-Time):

6
If you agree it is not in fact malware please find a way to recognize the false positive and allow me to receive the folder and use the beta application.v

[mariush]

lethedoom, when LameXP starts it creates a temporary folder on your hard drive and extracts several applications into that folder.

One of those applications is called lxp_mpg123.exe and that's probably the file that's one of the reasons antivirus software may report it as virus.
That's now the case with Avira and Ikarus as you can see here: https://www.virustotal.com/en/file/eddb524969865500ae44dd9a80a679d342ee6755e3bda5877f9fa3729b396038/analysis/1417295691/ (virustotal report for lxp_mpg123.exe).

LameXP.exe itself is compressed with UPX, the same executable compressor that's used in lxp_mpg123.exe

UPX is a legitimate compressor but the compression techniques it uses are often used in warez and trojans and dubious applications so it's normal that some antivirus software will do a false positive from time to time.

Mulder, I personally really don't see the point of compressing the executables with UPX.

upx says: 18203136 <- 16486912 90.57% win32/pe lame.exe

So you've saved a bit fat 2 MB by compressing your executable but you added the risk of antivirus software detecting your application as malware.

In the world of 1-4 TB hard drives people won't care that your application is 30-50 MB instead of 20 MB.
There's also no point in compressing those external executables when you can already compress them inside your main executable. As a suggestion - and I'm not sure, didn't bother to check source code, probably this is how you already do it now - you could 7z the files and embed the 7z inside the executable and you have a free 7z decoder library to unpack the contents nice and fast.

In addition, there's really no point in extracting all those files every time the application launches. Why not unpack the needed application when an encoding job is actually started?

Also... nowadays it really doesn't matter that much but in the past people with SSD drives would probably have cared about programs writing stuff to their boot drive at every launch.

And btw, I went into Advanced options and unchecked "Stored temporary files" and selected another folder and those executables are still unpacked there in the system default temp directory.

[LoRd_MuldeR]

UPX is a legitimate compressor but the compression techniques it uses are often used in warez and trojans and dubious applications so it's normal that some antivirus software will do a false positive from time to time.

I agree with this. But the conclusion to draw can not be that legitimate software should stop using a legitimate compressor, just because some malware uses the legitimate compressor!

The job of an Antivirus is to block malware while not affecting legitimate software in any kind of way. If legitimate software is affected, this is a bug in the Antivurs software and needs fixing in the Antivirus software.

Suspecting software of being malware, just because it uses an EXE packer, is just plain stupid! It's an invalid generalization, just like:
"Since 99% of all terrorists had bread for breakfast the day they went on rampage, all people who eat bread for breakfast probably are terrorists".

Antivirus software must be aware of "EXE packers", yes. But by analyzing the decompressed binary code in memory, not by analyzing the compressed code in the EXE file or, even worse, by stupid/invalid generalizations.

If we are at the point where Antivirus companies decided which legitimate techniques may be used by software developers and which legitimate techniques have to be avoided, because otherwise you will be blocked, there is only one name for this: Blackmail. And this cannot (and will not) be tolerated. So, this alone, is more than enough reason to continue using UPX, until even that last intellectually challenged person at those Antivirus companies has finally understood it.

Fortunately, Windows 8 ships with a (decent) free Antivirus software, so less and less people will pay for (crappy) Antivirus products. So, hopefully, most of the Antivirus companies will either change their field of business or go bankrupt...

[/rant]


In addition, there's really no point in extracting all those files every time the application launches. Why not unpack the needed application when an encoding job is actually started?

It was major design decision to completely setup the application "environment" during the startup sequence. It means that, once the application has been started, we can be sure that all the required tools are in place and can be used when needed. If anything goes wrong during initialization, the application won't even launch. So you get either a 100% working state or nothing at all. You never get the application in some semi-broken state.

Extracting the tools "on demand" would be possible, but then errors would be much more difficult to handle. If anything goes wrong during extraction, it would probably happen in some background worker thread where the tool happens to be accessed for the first time. Propagating the error to our GUI/Main thread and finally having to stop all the other worker threads, before we can shut down "gracefully" would be much more complex and error prone than the current method...


And btw, I went into Advanced options and unchecked "Stored temporary files" and selected another folder and those executables are still unpacked there in the system default temp directory.

This option only controls where intermediate Wave files will be located. Extracting the tools happens in a much earlier stage of the initialization process, long before any user options are loaded.

[mariush]

So what are you really trying to do, are you on a crusade against antivirus software, or are you simply trying to write good software?

At some point, you drop the idealism and put your "customers" first, the people using the software. Your small application with maybe a few thousand active users is a drop in the ocean, you're not a priority for antivirus software makers. But you may be alienating people with your choices.

You have a large variety of users using your software, and not all of them are smart. Some may be so stupid they won't even understand what the error messages say, they'll just see the antivirus say it's a virus and they'll remove the application and stop using it for ever. Once trust is broken, they may never use it again.

In this particular case, using that compressor only has downsides. It's a poor use of technology. (but then again, it's not the only thing you're using just because you can, like those sounds in the license agreement and about screens)

You're compressing your application to 90%, so you're not saving significant disk space... you basically saved about 2 MB.
You're increasing the load time of your application because any antivirus software will have to load those 20 MB in memory, decompress it, scan for viruses and then allow the process to start.

I would also say you're making your own software harder to update but I guess this (how you update your software) is entirely your choice. For example, since you're embedding all those files inside the executable, I would take advantage of this and change the update mechanism to either download the full setup (20 MB or something) or choose to download a "binary patch" that you can simply create using a software like xdelta ( http://xdelta.org/ open source, you can easily incorporate the patch functionality in the app). So instead of downloading 20 megs, the update can download 1-2 MB of diff, create a new .exe from the old one and the information in the patch file and then replace the old executable. Lots of people still download with 50-100 KB/s (as you can see for yourself if you check the download logs) so spending just 10-15 seconds to download a patch instead of 5 minutes would only benefit and would be less annoying to users.

Using upx simply screws this up, because even a single byte change would change the whole executable after compression and prevent you from making a proper binary diff between two executables.


It was major design decision to completely setup the application "environment" during the startup sequence. It means that, once the application has been started, we can be sure that all the required tools are in place and can be used when needed. If anything goes wrong during initialization, the application won't even launch. So you get either a 100% working state or nothing at all. You never get the application in some semi-broken state.


I'd rather have the application self-contained in a folder, where I put it. If I install it in D:\Programs\Lame , I don't expect it to write tens of megs to c:\ [...] \ TEMP folder. I'd rather have a Lame\Tools or Lame\Temp folder created automatically and so on. Or let user choose.
Maybe I run my Windows from a 64 GB SSD and I only have 300-500 MB free on the SSD. I wouldn't like to kill write cycles in those 300-500 MB of free space with 20-30 MB of tools. I know, it's unlikely, but you never know.

Also consider that you may want to make a "portable" version of the application, in which case having the files extracted in a subfolder would make it easy for you to just set some flags inside your application to just check for existence of those files at start instead of trying to unpack them from the executable each time.

[lethedoom]

Well, even if your cause is just since I use Windows 7 and thus require some anti-virus program, all of which read the test files as suspected virus, I will not be able to acquire and try the betas under present circumstances. Fortunately the LameXP v4.10 Setup (21.0 MB) download and 4.10 final zip download are not blocked today by Avast and hopefully neither will final 4.11 be blocked. Thanks again for your generous provision of this freeware tool. In my view the free anti-virus program providers are internet public health workers and not bad guys. My problem with Avast is it will not let me override their 'suspect' label and are slow to test and certify as safe files that are submitted for reconsideration.

[SeeMoreDigital]

Well, even if your cause is just since I use Windows 7 and thus require some anti-virus program...Hmmm...

When I had Windows 7 installed, I ran Microsoft's own Security Essentials anti-virus software. Same too with Windows 8, Windows 8.1 and now with Windows 10. I've never seen a virus warning when installing LameXP.

[LoRd_MuldeR]

So what are you really trying to do, are you on a crusade against antivirus software, or are you simply trying to write good software?

What a specific proprietary so-called "Antivirus" software does (or does not do) is completely irrelevant to my decisions. As long as my software doesn't do anything that, without any doubt, classifies as "malware behavior" - and that certainly is not the case here - any so-called "Antivirus" software is strictly forbidden to interfere with my software in any possible kind of way. If it does so anyway, that's a bug, in the particular so-called "Antivirus" software. Bugs can happen. Bugs do happen. But I can only fix bugs in my own software. It's definitely not my job to fix bugs in proprietary so-called "Antivirus" software, created by some commercial company that I have no relation to. Also, I certainly will not implement any workarounds for buggy so-called "Antivirus" software, since that is completely pointless! There are hundreds of so-called "Antivirus" products out there. And since those products are proprietary software, we can only speculate what has gone wrong "behind the scenes" when our legitimate software gets blocked for no good reason. Even worse, behavior of the proprietary so-called "Antivirus" software can change at any time, e.g. with the next signature update. So should I implement highly speculative workarounds for hundreds of different so-called "Antivirus" programs? Workarounds that, if at all, will help only for a short time? Workarounds that would forbid me to make use 100% legitimate techniques? Certainly no, not in this life! :)

So what can be done? Educate people! If somebody is a paying customer of a so-called "Antivirus" software and that software doesn't work correctly, he or she must contact the support team and file a bug report. That's the one and only way to get the bugs fixed. Also, if the manufacturer doesn't fix bugs (in time), it's up to the paying customer to cancel his contract and get his or her monkey back. You certainly don't have to stick with a product that is a buggy mess...


Hmmm...

When I had Windows 7 installed, I ran Microsoft's own Security Essentials anti-virus software. Same too with Windows 8, Windows 8.1 and now with Windows 10. I've never seen a virus warning when installing LameXP.

Security Essentials seems to be one of the Antivirus programs that tend to be less overcautious ;)

And it's also clear why: Microsoft decided to give away Security Essentials for free, so it doesn't need to continuously scare the user with (alleged) "virus alters", in order to legitimize the subscription fees...

(It's safe to assume that in other Antivirus companies it's the marketing department who tells their programmers how often, e.g. at least once per week, each customer must see a virus alert)

[LoRd_MuldeR]

I'd rather have the application self-contained in a folder, where I put it. If I install it in D:\Programs\Lame , I don't expect it to write tens of megs to c:\ [...] \ TEMP folder. I'd rather have a Lame\Tools or Lame\Temp folder created automatically and so on. Or let user choose.
Maybe I run my Windows from a 64 GB SSD and I only have 300-500 MB free on the SSD. I wouldn't like to kill write cycles in those 300-500 MB of free space with 20-30 MB of tools. I know, it's unlikely, but you never know.

Also consider that you may want to make a "portable" version of the application, in which case having the files extracted in a subfolder would make it easy for you to just set some flags inside your application to just check for existence of those files at start instead of trying to unpack them from the executable each time.

It is already possible, for quite some time now, to use your own tool binaries.

See here:
http://muldersoft.com/docs/lamexp_faq.html#3d6684e9

[LoRd_MuldeR]

LameXP Test-Build r1608 :eek:

New build. This should fix a few bugs introduced in the previous build(s). So if you encountered strange crashes, this will fix it, hopefully.

[lethedoom]

Avast is blocking LameXP Test-Build r1608 too. I thought about accepting the suggestion to change to Security Essentials, but the reviews deem it so weak I will not. For what it is worth I followed my support request to Avast asking them to agree their label is a false positive with a forum posting. I hope it will get some response.

[lethedoom]

I received an email from Avast acknowledging that their decision had been a false positive. I was able to download the newest Test version, so they have updated their virus definitions to fulfill their stated intention. fyi:
Hello
Thank you for contacting our support center with your concerns.Thank you for your message.It's false positive. The detection will be fixed in the next VPS.We are sorry for the inconvenience.If I can be of any further assistance, please do not hesitate to contact me again.
Best regards,
Lukas Havel
Technical Support Specialist

www.avast.com

Ticket Details
Ticket ID: YXL-216-11481
Department: Virus and FP reports
Type: FalsePositive
Status: On Hold
Priority: Normal
Support Center: https://support.avast.com/index.php?

I converted two groups of .shn files to .mp3 without any problems with this test version.

[LoRd_MuldeR]

LameXP Test-Build r1624 :eek:

More refactoring has been done. But, most important, I tracked down and fixed (hopefully) a long-standing problem in the worker thread creating code, which caused an unnecessary slow-down of the "worker" process creation and also made the GUI less responsive than it should be. Things appear to run quite a bit more smoothly now, especially when you crank up the number of parallel encoder instances! Limit for the number of parallel instances has been raised to 32 too...

[LoRd_MuldeR]

LameXP Test-Build r1628 :eek:

LameXP r1582 vs. r1624:
http://i.imgbox.com/3G4Zr9xT.png (https://vimeo.com/114437958)

[SeeMoreDigital]

Jeez... That looks fast :)

[mariush]

86 wav files that are a few seconds each... seems kind of a pointless test.

[LoRd_MuldeR]

86 wav files that are a few seconds each... seems kind of a pointless test.

Not pointless at all, considering that this was chosen specifically to illustrate the specific problem that has been fixed recently. Nowhere I said that this is supposed to be the most common use case :)

Anyway, it should be clear that the longer the individual files are, the more time each encoding task takes to complete - and thus the "freeze" that did happened on the creation of each new task will become less apparent.

Conversely, with an increasing number of CPU cores the problem increases! I have report from one person who ran a test with ~1200 regular audio files on a 20 cores machine that there was a huge speed up.

[lethedoom]

I have downloaded and used the test builds provided on 2014-12-13, 2014-12-08, 2014-12-06, 2014-12-05,2014-11-30 since my antivirus program stopped blocking the zips. Taking your point that more instances are better I use 32 on my i5 dual core Win 7 PC with the test builds and I find the increase in speed quite substantial compared to LameXP v.4.10 final. I download trade friendly artist live concerts (usually flac) with Deluge and convert them to mp3 with LameXP almost daily. Thanks again for your very useful tool which you share as a gift.

[LoRd_MuldeR]

I have downloaded and used the test builds provided on 2014-12-13, 2014-12-08, 2014-12-06, 2014-12-05,2014-11-30 since my antivirus program stopped blocking the zips. Taking your point that more instances are better I use 32 on my i5 dual core Win 7 PC with the test builds and I find the increase in speed quite substantial compared to LameXP v.4.10 final. I download trade friendly artist live concerts (usually flac) with Deluge and convert them to mp3 with LameXP almost daily. Thanks again for your very useful tool which you share as a gift.

Just to clarify: I did not say "that more instances are better" in general. What I said is that the recent fix will probably give the most noticeable improvement when you run a high number of instances in parallel. But that does not mean that you are supposed to crank up the number of parallel instances just because you can. It usually doesn't make much sense to run more instances in parallel than you have (logical) CPU cores available - even though this should work much better now with the "new" version. Furthermore, because of the possible I/O bottleneck, running too many instances in parallel may even considerably slow things down! Though the use of SSD's should eliminate the I/O bottleneck issue to a large extent...

[Romario]

@ LoRd_MuldeR

Can you, please, give me all changelogs from 4.11 beta 1 to newest beta 8 ? Thanks in advance.


Another question for you : What if someone have 18-core beast Xeon ? Is then running more instances in parallel much better ??? Or on 8-core 5960X, for example ? How good is your latest optimisations ?

[LoRd_MuldeR]

Can you, please, give me all changelogs from 4.11 beta 1 to newest beta 8 ? Thanks in advance.

As always, you can find the log at the official Git repository:
https://github.com/lordmulder/LameXP/commits/

Another question for you : What if someone have 18-core beast Xeon ? Is then running more instances in parallel much better ??? Or on 8-core 5960X, for example ?

Doesn't change anything: It still doesn't make much sense to run more instances in parallel than you have CPU cores. Only the number of CPU cores is much higher ;)

(Also with 18 instances running in parallel, you better have a decent SSD and/or RAID in order to avoid I/O bottleneck!)

[LoRd_MuldeR]

LameXP Test-Build r1636 :eek:

[lethedoom]

It usually doesn't make much sense to run more instances in parallel than you have (logical) CPU cores available - even though this should work much better now with the "new" version. Furthermore, because of the possible I/O bottleneck, running too many instances in parallel may even considerably slow things down! Though the use of SSD's should eliminate the I/O bottleneck issue to a large extent...

I have no doubt your opinion is more likely correct than my ungrounded guess.

On my dual core win 7 pc I have 4 logical cores. If I limit the instances to 4 converting a 16 file set LameXP initially works on four and the rest are added one at a time as a slot opens after a file is completed. If I do the same task with enough more instances initially all the files are displayed and all work at the same time. I have supposed that Windows distributes the available computing ability with some efficiency, but I have no understanding of problems like the I/O bottleneck. Since I don't see that it slows things down on my pc I like seeing the whole job displayed at once, so I am grateful that you have expanded the number of possible multi-threading running instances.

[LoRd_MuldeR]

On my dual core win 7 pc I have 4 logical cores. If I limit the instances to 4 converting a 16 file set LameXP initially works on four and the rest are added one at a time as a slot opens after a file is completed.

If you have selected N parallel instances, then LameXP will launch exactly N encoding jobs right at the start. From then on, every time one of the running jobs has finished, it will launch the next job.

In other words, LameXP makes sure that, at any given moment, there will be N running encoding jobs. At least as long as there are still enough pending jobs left...

If I do the same task with enough more instances initially all the files are displayed and all work at the same time. I have supposed that Windows distributes the available computing ability with some efficiency, but I have no understanding of problems like the I/O bottleneck. Since I don't see that it slows things down on my pc I like seeing the whole job displayed at once, so I am grateful that you have expanded the number of possible multi-threading running instances.

All processes (threads) running on you computer must share the available CPU cores. If you have 4 (logical) CPU cores, then at most 4 processes can be running concurrently (i.e. at the same time). Of course, you can create even more processes than you have CPU cores. And indeed, if you look in your Taskmanager, you will probably see that there exist 50+ processes on your Windows system, even right after the login. Still, at most 4 of these processes can actually be executing on the CPU at the same time, no matter what! The scheduler (http://en.wikipedia.org/wiki/Scheduling_%28computing%29) will pick a certain process that is "ready to execute", give that process some amount of time to run on the CPU and finally put it to "sleep" again. It then will pick another process. And so on...

Consequently, even if we assume that each encoder process can only utilize a single processor core (i.e. we assume that the encoder processes are not muti-threaded internally), then running 4 encoder processes in parallel will already utilize your Quadcore to the full! Running even more encoder processes in parallel is possible, for sure. But will it give a speed-up, compared to running "only" 4 instances in parallel? Probably not! That's because these processes are now competing for the CPU. That means: If you run 16 instances in parallel, the overall batch encoding task (all files in your queue) will not complete earlier, compare to running "only" 4 instances in parallel. That's because in the "16 instances" case, more instances run in parallel, but each instance also runs slower, since it needs to share the CPU! Even worse: In the "16 instances" case, more processes will be accessing your HDD concurrently, which means that the HDD can easily become a bottleneck!

[mariush]

My explanation... perhaps in a language that's easier to understand.

LameXP doesn't do the encoding/conversion of audio files itself, it simply launches stand-alone applications in the background, depending on what type of file you selected to encode and what format is the destination file.
Those applications that run hidden in the background and do the conversion of each audio file simply report their progress to LameXP and LameXP shows you in a nice way how everything goes.

With that option, LameXP lets you select how many encoding jobs can be started and can run simultaneously but as far as I know, it can't really control how many "real" threads are created by those encoding applications it starts in the background.
For example, If you have 100 audio files that you wish to encode and you entered 4 in that options box, LameXP will start 4 copies of the encoding software suitable for that conversion and tell each copy to convert one audio file. As soon as one of those copies finishes the job, it starts another copy with another audio file, until all 100 audio files are done.

Some encoding/conversion applications are mostly single threaded, meaning there's one thread that's important and does probably 95-99% of the work. Such applications are for example Lame - the mp3 encoder used by LameXP in the background - or FLAC, the encoder that converts audio files to flac format.
When such applications are started by LameXP, the operating system will automatically put them on cores of your processor, trying to keep all cores as busy as possible. So, if you have 4 cores and LameXP starts 4 copies of lame or flac, each core should run a copy of that software.. should, but not always - the operating system also keeps track of other applications running on your computer and their importance and tries to make sure all will get processing time.

If you have a very fast processor with very fast cores, it may be the case that an encoding application like Lame or Flac is programmed in such a way that it would not use a core to its limits, so it may make sense to let LameXP start more copies of that encoding application than the available cores in your system and let the operating system manage them. For example, if flac encoder only uses 70% of a core when doing its job and you have 4 cores in your computer, you could try to start 8 copies of flac encoder and hopefully each core will handle 2 cores at the same time. Naturally, those 2 copies now take turns using that core and probably each copy will use only about 45% of the core so each copy will encode slower but you're encoding twice the number of files at one time ... at the end of the day your 100 audio files will be converted faster, as long as the other components in your computer keep up (if your hard disk can read the audio files fast enough and feed the encoders new data)

Now of course, this all works for single threaded applications. There are encoding applications like aften - the encoder used by LameXP to create .ac3 files - which can create multiple threads by themselves in order to use the processor as efficient as possible. On my computer, aften automatically detected that I have an eight core processor (AMD FX-8320) and after I launched it, it automatically created 8 threads which the operating system spread on all cores and the software started to encode the audio file using all eight cores.
I'm not sure, I don't know if LameXP is "smart" enough to detect this difference. If it doesn't... then in your fictional computer with 4 cores, LameXP would start 4 copies of aften because you said you wanted 4 encoding jobs at same time, but each copy of aften would create its own 4 threads (as it detects your processor as quad core) so now there are 16 threads running at the same time on four available cores, so all 16 threads "fight" for time on those cores. That's not good.

Sidenote.. even if you have a fast processor you have to think about other things like the hard disk. If you have all audio files on one hard disk and a fast processor with lots of cores, for example and eight core processor, you may want to encode eight uncompressed wav files to mp3 but your hard disk may not be able to read those 8 wav files fast enough to keep those eight copies of mp3 encoder happy.

That's where an application like LameXP could be smart and look up in the encoding queue to see where the input files are located and maybe run jobs with input files on different partitions or hard disks.. or do other tricks like buffering input data to memory and so on.

-

ps. I did the stupid thing of installing LameXP just to check what I wrote here, but clicked on decline on the license window, as I was annoyed by the sound. Instead of just closing, it wants to uninstall which I didn't allow. Now if I try to launch the application it says I didn't accept the license and tries to uninstall itself. Dude, maybe I didn't have time to read the license to make sure I agree with it and want to read it at later time.. just close the application and show the license next time app. starts. Don't force uninstall... damn.

[LoRd_MuldeR]

I did the stupid thing of installing LameXP just to check what I wrote here, but clicked on decline on the license window, as I was annoyed by the sound. Instead of just closing, it wants to uninstall which I didn't allow. Now if I try to launch the application it says I didn't accept the license and tries to uninstall itself. Dude, maybe I didn't have time to read the license to make sure I agree with it and want to read it at later time.. just close the application and show the license next time app. starts. Don't force uninstall... damn.

Please just run the application again and then you should be able to revise your choice...

If you have a very fast processor with very fast cores, it may be the case that an encoding application like Lame or Flac is programmed in such a way that it would not use a core to its limits, so it may make sense to let LameXP start more copies of that encoding application than the available cores in your system and let the operating system manage them. For example, if flac encoder only uses 70% of a core when doing its job and you have 4 cores in your computer, you could try to start 8 copies of flac encoder and hopefully each core will handle 2 cores at the same time.

No, it's not possible that a thread "uses [only] 70% of a core". From the operating system's perspective, there are only two distinct states of a processor core: Either some thread is currently scheduled to the processor core (i.e. that thread currently has control over the CPU core), in which case the CPU core is considered "busy", or no thread is currently scheduled to the processor core, in which case the CPU core is considered "idle". There is no intermediate state between these two states. Consequently, the so-called "CPU utilization" that you see in Taskmanager is nothing but the fraction of time that the CPU has been in "busy" state - as opposed to the fraction of time that the CPU has been in idea state.

So, if you see a "CPU utilization" of, e.g., 70%, then this does not mean that the application "uses only 70% of the CPU". Instead, what it means is: During the last period, the CPU (core) has been in "busy" state 70% of the time and it has been in "idle" state 30% of the time (note that "CPU utilization" can only be measured over a period). Or, in other words: In 70% of the time, a "ready to execute" thread had been scheduled to the CPU (core), while in the remaining 30% of the time, there simply was no "ready to execute" thread available that could have been scheduled to the CPU. Now you may wonder: How can it be possible that, sometimes, no thread on the system is "ready to execute" and thus the CPU (core) becomes idle? The answer is: In this situation all the threads either are waiting for user input (keep in mind that, in a GUI application, threads spent 99.9% of their time waiting for user input events!) or they are forced to wait for pending I/O operations.


BTW: Yes, modern CPU cores contain multiple "execution units", so that they can execute SSE and AVX instructions (each SSE/AVX instructions performs multiple computations "at once", so it needs several execution units). This means that, if the "active" thread does not use highly optimized SSE/AVX code, then not all of the CPU core's "execution units" are actually busy while the thread is executing. Still, from the operating systems perspective, the CPU is simply in "busy" state. It is not technically possible to schedule more than one thread to the same CPU core at the same time in order to exploit those "unused" execution units - except via Hyper-threading. But Hyper-threading uses a trick: It simulates two (logical) CPU cores for each physical CPU core, so the operating system will "see" twice the number of CPU cores. Nonetheless, even with Hyper-threading, still each (logical) CPU core can only be either in "busy" or in "idle" state. And still only a single thread can be scheduled to each (logical) CPU core at any given moment in time. The two logical cores that map to the same physical cores will of course have to share the core's execution units, which increases the "utilization" of these execution units.

[LoRd_MuldeR]

LameXP Test-Build r1646 :eek:

This should fix a "silent" crash that happened during application shutdown and caused the temporary files to not be removed properly.

(Lesson learned today: If a crash occurs inside the destructor of a global object, i.e. after the "main" function has returned, the process will just die silently. Neither will the unhandled exception handler be invoked in this case, nor will the Visual Studio debugger be able to catch this event. And, since global object are destroyed in an arbitrary order - and not all of them get destroyed, if one of the destructors has crashed - this situation is not very funny to debug ^^)

[schiff1108]

LameXP will re-embed cover art, if the selected encoder supports that. LAME does. QAAC does not. Use Nero AAC ;)

(It may be possible to add the cover art to the QAAC-encoded MP4 file later with some other tool, but LameXP does not implement that currently)

... any news about re-embed covert art for QAAC-endoced mp4 files?
Nevertheless, LameXP is a great programme. Thanks.

[LoRd_MuldeR]

... any news about re-embed covert art for QAAC-endoced mp4 files?
Nevertheless, LameXP is a great programme. Thanks.

Do you have any information on how to embed cover artwork with QAAC? Does QAAC support this "out of the box" now? :confused:

[Octo-puss]

Can I use LameXP to reencode FLAC files using the newer FLAC? Not that I need to do it, but I read somewhere that there were some changes to metadata and other stuff that sounds partially interesting.

[schiff1108]

Do you have any information on how to embed cover artwork with QAAC? Does QAAC support this "out of the box" now? :confused:

Here I was reading that there is an option to include artwork:
https://github.com/nu774/qaac/wiki/Command-Line-Options

I am using qaac 2.44 which works very fine for me.

I had a long debate with myself whether I will use in future Nero AAC or QAAC. Finally I have decided for QAAC after lots of hearing tests.

[LoRd_MuldeR]

Can I use LameXP to reencode FLAC files using the newer FLAC? Not that I need to do it, but I read somewhere that there were some changes to metadata and other stuff that sounds partially interesting.

You can re-encode existing FLAC files to the FLAC again, yes. If that was the question :confused:

Anyway, there have not been any changes to the FLAC file format since somewhere in 2007. Latest version of the FLAC encoder has some performance improvements and a few minor fixes, but that's it:
https://xiph.org/flac/changelog.html

So the only reason for re-encoding FLAC to FLAC that I can think of is when the "original" FLAC file was created with "fast" FLAC settings and now you want to re-encode with "slow" FLAC settings in order to save a few bytes.

Here I was reading that there is an option to include artwork:
https://github.com/nu774/qaac/wiki/Command-Line-Options

I think with option "--artwork" we can do something ;)

[LoRd_MuldeR]

Here I was reading that there is an option to include artwork:
https://github.com/nu774/qaac/wiki/Command-Line-Options

I am using qaac 2.44 which works very fine for me.

I had a long debate with myself whether I will use in future Nero AAC or QAAC. Finally I have decided for QAAC after lots of hearing tests.

As it turns out, LameXP was already using the "--artwork" option of QAAC all the time, but due to a bug in QAAC the artwork file provided by LameXP could not be read :(

QAAC fails to open the file for reading when the file is already open for reading in other process (and of course the file is already open in LameXP for reading), because it requests exclusive access, for an unknown reason.

The fix is underway now:
https://github.com/nu774/qaac/pull/28

[LoRd_MuldeR]

LameXP Test-Build r1655:

I also updated the QAAC Add-in to QAAC v2.44, including an important fix (https://github.com/nu774/qaac/pull/28) for a problem that has caused the "--artwork" option of QAAC to not work with LameXP:
http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/Testing/LameXP.qaac-addin.2014-12-25.zip/download

Also see QAAC install instructions in the new LameXP Manual here:
http://lamexp.sourceforge.net/doc/Manual.html#qaac-apple-aac-encoder

Merry Christmas http://www.santatulsa.com/santa-emoticon.gif

[Techie007]

Thank you for this easy to use audio encoding software! I have recommended it numerous times. However, I have a question: Why does LameXP extract its encoders/decoders each time it starts and delete them when it exits? I would prefer to have an option for them to be copied to Program Files during installation and left there so that LameXP could load faster.

[LoRd_MuldeR]

Thank you for this easy to use audio encoding software! I have recommended it numerous times. However, I have a question: Why does LameXP extract its encoders/decoders each time it starts and delete them when it exits? I would prefer to have an option for them to be copied to Program Files during installation and left there so that LameXP could load faster.

Hi, Techie007.

This was a deliberate design decision to create a fully self-contained application. The user shouldn't even need to worry about such implementation details.

Even on my eight-year-old Core2 machine, extracting the binaries takes only about 1.5 seconds (and that is with MSE enabled). Thus, even tough LameXP probably could be made starting faster, the current startup delay is not really an issue.

If the startup takes considerably longer on your system, then you probably are the victim of a resource hog, camouflaged as "antivirus software". So please don't shoot the messenger ;)

[BoosterPack]

Hello,

I am experiencing error when trying to load a music file for converting. I tried various types of files (mp3 and FLAC) and still get the same error. Any advice to solve this? Thanks.

http://i60.tinypic.com/59sf1t.png

[LoRd_MuldeR]

Hello,

I am experiencing error when trying to load a music file for converting. I tried various types of files (mp3 and FLAC) and still get the same error. Any advice to solve this? Thanks.

http://i60.tinypic.com/59sf1t.png

Hello, BoosterPack.

Well, as the error message indicates, one of the files that you were trying to add has been rejected, because its type could not be recognized by LameXP/MediaInfo :confused:

Can you provide more information about that file? I suggest you open the "problematic" file with MediaInfo (http://www.videohelp.com/tools/MediaInfoXP) and post the MediaInfo report here...

[Techie007]

If the startup takes considerably longer on your system, then you probably are the victim of a resource hog, camouflaged as "antivirus software". So please don't shoot the messenger ;)

We can definitely rule that out. :) My system is clean, and is running an i7-3770K and a SSD. When launching LameXP, its splash screen appears immediately for 1.5 seconds before the LameXP UI appears. After finding out with Process Monitor what it was doing during that time, I just thought it would be nice to eliminate that delay.
The delay that really bothers me is the six second delay when starting LameXP via right-clicking an audio file and selecting Convert with LameXP. LameXP loads as before, but another six seconds elapse before the audio file is added to the source list. Perhaps this delay would be easy to reduce? I am running the latest stable version (although it has always had this behavior, on several different computers over the years).

[mike20021969]

right-clicking an audio file and selecting Convert with LameXP.

@LoRd_MuldeR
Could you include an option to not add context menu entries during installation?

I like to keep right-click menu totally minimal, but I always have to trawl through the registry after installing to delete all the additional entries LameXP creates.

Thanks.

[LoRd_MuldeR]

We can definitely rule that out. :) My system is clean, and is running an i7-3770K and a SSD. When launching LameXP, its splash screen appears immediately for 1.5 seconds before the LameXP UI appears. After finding out with Process Monitor what it was doing during that time, I just thought it would be nice to eliminate that delay.

So the startup delay shouldn't be a big issue for you either :)


The delay that really bothers me is the six second delay when starting LameXP via right-clicking an audio file and selecting Convert with LameXP. LameXP loads as before, but another six seconds elapse before the audio file is added to the source list. Perhaps this delay would be easy to reduce? I am running the latest stable version (although it has always had this behavior, on several different computers over the years).

That's a completely different topic! ;)

Here you need to understand what really happens when you open a file (or multiple files) via "Convert with LameXP" from the Windows Explorer. For each file that you have selected, the Windows Explorer will launch a new instance of LameXP and pass the respective file as a command-line argument. So, if you have selected 15 files (for example), then the Windows Explorer will actually launch 15 instances of LameXP - one instance for each file! That's how the Windows Explorer handles things, so there's not really anything we could do about that (maybe except by installing our own Shell Extension). Of course, you wouldn't like to see 15 separate LameXP application windows pop up, right ??? :eek:

Therefore, LameXP implements the single instance pattern, i.e. only one instance is running at a time. It works in the following way: The very first instance of LameXP that is launched will become the "master" instance. All other instances that are launched subsequently will become "slave" instances. Now, what each of these "slave" instance does is the following: First it will establish an IPC (http://en.wikipedia.org/wiki/Inter-process_communication) channel to the "master" instance, secondly it will transmit its own command-line over to the "master" instance (trough the IPC channel), and finally it will exit silently. Thus, even though the file has originally been opened (by Windows Explorer) via a new "slave" instance of LameXP, it will show up in the "master" instance of LameXP.

Of course the "master" instance cannot know at which time it will receive the next command from a "slave" instance, if at all. Still, we want the "master" instance to collect all pending commands and execute them at once! Otherwise, if an incoming command was executed immediately, it could easily happen that LameXP starts adding the first file, while more commands (files) are about to arrive! That's obviously not a good idea, because some commands could get lost! For this reason, when the first command arrives, LameXP will start a timer. Then LameXP is going to sit tight and wait for more commands to arrive. The actual processing won't start, until the timer triggers. And that probably is the delay you are referring to!

(I hope you understand now that this delay is required and cannot easily be removed)

[LoRd_MuldeR]

Could you include an option to not add context menu entries during installation?

Not really, because that is something that is not handled by the installer. It will be handled by the application, later on.

I like to keep right-click menu totally minimal, but I always have to trawl through the registry after installing to delete all the additional entries LameXP creates.

You shouldn't have to delete anything (by hand). You can enable or disable the shell-integration at any time, in the options menu.

[mike20021969]

You shouldn't have to delete anything (by hand). You can enable or disable the shell-integration at any time, in the options menu.

I will do that during next release install.

Would that remove the registry entries as well?

[LoRd_MuldeR]

Would that remove the registry entries as well?

It is supposed to, yes.

[mike20021969]

It is supposed to, yes.
Thanks :cool:

[Techie007]

Of course the "master" instance cannot know at which time it will receive the next command from a "slave" instance, if at all. Still, we want the "master" instance to collect all pending commands and execute them at once! Otherwise, if an incoming command was executed immediately, it could easily happen that LameXP starts adding the first file, while more commands (files) are about to arrive! That's obviously not a good idea, because some commands could get lost! For this reason, when the first command arrives, LameXP will start a timer. Then LameXP is going to sit tight and wait for more commands to arrive. The actual processing won't start, until the timer triggers. And that probably is the delay you are referring to!

So the problem is that if your main application does anything else, it may miss IPC events? Some time ago, I wrote a simply GUI for opusenc that also requires support for multiple opens in Windows Explorer. I used window titles and windows messages as the notification method between the slave and master applications. It collects Windows Explorer's maximum of 15 files almost instantly, and I have never had it miss any files. Messages sent with the PostMessage API just get added to the window's message que if the recipient application is busy, and as long as the slave application(s) keep running, the master can read their window titles any time it's ready.

The code below is in VB, but perhaps it will give you some ideas:

{modOpusGUI.bas}

Public Sub Main()
On Error Resume Next
Dim Tries As Long
Dim hWnd As Long
If App.PrevInstance Then
'20 * 250 ms = wait up to 5 seconds for GUI to be ready
For Tries = 1 To 20
SleepEx 250, 0
hWnd = FindWindowA(vbNullString, "Opus Encoder GUI")
If hWnd <> 0 Then
frmDelegate.DelegateCmd hWnd, Command
Exit Sub
End If
Next
End If

frmOpusGUI.Show
End Sub
______________________________

{frmDelagte.frm}

Public Sub DelegateCmd(hWndGUI As Long, Cmd As String)
On Error Resume Next
Me.Caption = Cmd
'Upon receving this message, the master application will read the window title from the hWnd
'we specified, and then send a WM_CLOSE message to our window to exit this slave instance.
PostMessageA hWndGUI, WM_AddFile, Me.hWnd, 0
'However, if the master instance fails to respond, this timer will ensure
'that this slave instance doesn't stay running in the background forever.
tmrTimeout = True
End Sub

Private Sub tmrTimeout_Timer() '10 second timer
On Error Resume Next
Unload Me
End
End Sub
______________________________

{frmOpusGUI.frm}

Private Sub Form_Load()
On Error Resume Next
Tag = Command
If Right(Tag, 1) = Chr(34) Then Tag = Mid(Tag, 2, Len(Tag) - 2)
If Tag <> "" Then AddFile Tag
Show

'Set the window message hook so we can intercept window messages
hHook = SetWindowLongA(hWnd, GWL_WNDPROC, AddressOf WindowProc)
'Now that I'm ready, change my window title so that slave instances can find me
Caption = "Opus Encoder GUI"
End Sub
______________________________

{modOpusGUI.bas}

Public Function WindowProc(ByVal hWnd As Long, ByVal uMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
On Error Resume Next
WindowProc = 0 'We handled the message

Select Case uMsg
Case WM_AddFile 'Message from slave application to add a file to the list
'Read the window title (filename)
PST1 = TitleFromHwnd(wParam)
'Close the slave application that sent the message
PostMessageA wParam, WM_CLOSE, 0, 0
'If the filename has quotation marks, remove them
If Right(PST1, 1) = Chr(34) Then PST1 = Mid(PST1, 2, Len(PST1) - 2)
If PST1 <> "" Then
frmOpusGUI.AddFile PST1
Else
frmOpusGUI.SetFocus
End If
Case Else
'Pass the message on to VB runtime to handle other messages
WindowProc = CallWindowProcA(hHook, hWnd, uMsg, wParam, lParam)
End Select
End Function

Public Function TitleFromHwnd(pHwnd As Long) As String
On Error Resume Next
If pHwnd = 0 Then Exit Function
TitleFromHwnd = String(255, 0)
PNU2 = GetWindowTextA(pHwnd, TitleFromHwnd, Len(TitleFromHwnd))
TitleFromHwnd = Left(TitleFromHwnd, PNU2)
End Function

Now, one thing with window messages is that they will hang your application until you have finished processing them (because the application redraw/mouse/keyboard messages are waiting later in the message que). So you may want to cache the WM_AddFile messages and then spool them one at a time with a fast timer so that your UI remains responsive if you have to do additional information processing on each file.

[LoRd_MuldeR]

So the problem is that if your main application does anything else, it may miss IPC events? Some time ago, I wrote a simply GUI for opusenc that also requires support for multiple opens in Windows Explorer. I used window titles and windows messages as the notification method between the slave and master applications. It collects Windows Explorer's maximum of 15 files almost instantly, and I have never had it miss any files. Messages sent with the PostMessage API just get added to the window's message que if the recipient application is busy, and as long as the slave application(s) keep running, the master can read their window titles any time it's ready.

The code below is in VB, but perhaps it will give you some ideas:
[...]

Now, one thing with window messages is that they will hang your application until you have finished processing them (because the application redraw/mouse/keyboard messages are waiting later in the message que). So you may want to cache the WM_AddFile messages and then spool them one at a time with a fast timer so that your UI remains responsive if you have to do additional information processing on each file.

I'm not using Window messages, because this is platform-specific technique. Instead, I'm passing IPC messages trough a shared memory area, organized as a ring-buffer and synchronized by system semaphores. This all is implemented via the Qt cross-platform application framework (src (http://sourceforge.net/p/mutilities/code/ci/master/tree/src/IPCChannel.cpp)). And it works pretty stable. So the problem is not that any IPC messages are getting lost on the way. The "problem" is more fundamental, and regardless of how exactly the IPC messages are passed around:

From the perspective of the the "master" instance, it is impossible to know when the next IPC message is going arrive. Or whether any more message will arrive at all. More specifically, after a certain number of message have been received already (maybe only one), we never know for sure whether we have all messages now, or whether the next messages is going to arrive shortly. Nonetheless, at some point, we will have to make a decision and say: "Okay, we assume that all messages have been received at this point, so we will launch our 'file analyzer' thread now - with the batch of pending files that we collected up to this point". Note that, analyzing the new files, is actually not a trivial task! So it's done in worker thread(s).

Of course, it still may happen that some files arrives "late". In particular, the file could arrive after we have already launched the worker thread, but before the worker thread has finished analyzing all files (from the previous batch). But what to do with such file that arrived "late"? We can't simply kill and restart the "file analyzer" thread; at least that wouldn't be a very good idea. So, currently, files that arrive while the application is "busy", e.g. while the "file analyzer" thread is still working, will simply be discarded. In order to minimize the chance that files will be discarded, we use a timer. The timer is started as soon as the first message arrives. And the "file analyzer" thread is not going to be launcher until the timer triggers...

[Techie007]

Of course, it may still may happen that some files arrives "late". In particular, the file could arrive after we have already launched the worker thread, but before the worker thread has finished analyzing all files (from the previous batch). But what to do with such file that arrived "late"? We can't simply kill and restart the "file analyzer" thread; at least that wouldn't be a very good idea. So, currently, files that arrive while the application is "busy", e.g. while the "file analyzer" thread is still working, will simply be discarded. In order to minimize the chance that files arrive "late", we use a timer. The timer is started as soon as the first message arrives. And the "file analyzer" thread is not going to be launcher until the timer triggers...

What's keeping you from dynamically adding files to the end of the "file analyzer" list while it is analyzing? Or at least, perhaps you could just cache the names of files that arrive while the "file analyzer" is running, and when the "file analyzer" is done, start it again with the cached list?

[LoRd_MuldeR]

What's keeping you from dynamically adding files to the end of the "file analyzer" list while it is analyzing?

The complete file list is passed to the "file analyzer" thread in the constructor. Once the "file analyzer" thread has been launched, there is no (easy) way for adding even more files to the list. That's because the Main/GUI thread cannot simply manipulate the "file analyzer" thread's internal data structures! As you might know, accessing the same data structures from different threads, results in "undefined behavior" (including program crash) - unless all the access to the "shared" data is synchronized very carefully. Also, while the "file analyzer" thread can send signals back to the Main/GUI thread, this is not possible the other way around. That's because the "file analyzer" thread is not actually running its own event loop.

Furthermore: Since the files have been received by the "master" instance in an arbitrary order, one of the first things that the "file analyzer" thread has to do is a natural order sorting of the file list - including special handling of playlist files. Now, if we wanted to add even more files to the list later on - after the files on the list had already been sorted and after some of these files have already been processed - this would mess up our whole ordering :eek:

Or at least, perhaps you could just cache the names of files that arrive while the "file analyzer" is running, and when the "file analyzer" is done, start it again with the cached list?

That would be a more feasible solution, I think. Though it would look somewhat strange if the progress window reaches 100% and closes, just to re-appear a few milliseconds later and restart from 0% again. Furthermore, even if we can restart the "file analyzer" thread many times, we certainly don't want to do that for each individual file. But if we don't use a delay at all - as you seem to suggest - then the very first file that is received unavoidably would be processed alone!

And, of course, if we process the incoming files in multiple small batches, rather than one single big batch, then establishing a proper sorting won't work either... (only within each batch, but not overall)

[BoosterPack]

Hello, BoosterPack.

Well, as the error message indicates, one of the files that you were trying to add has been rejected, because its type could not be recognized by LameXP/MediaInfo :confused:

Can you provide more information about that file? I suggest you open the "problematic" file with MediaInfo (http://www.videohelp.com/tools/MediaInfoXP) and post the MediaInfo report here...

Ok I know what the problem was. I needed to run the program as administrator. Thanks for your help!

[LoRd_MuldeR]

I needed to run the program as administrator.

That shouldn't be necessary. So I somehow doubt that this was really the problem!

Again, if your file is rejected for some reason, then I urge you to post some logs and/or MediaInfo reports, so we can figure out what is actually happening...

[schiff1108]

LameXP Test-Build r1655:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2014-12-25/LameXP-TEST.2014-12-25.zip/download

I also updated the QAAC Add-in to QAAC v2.44, including an important fix (https://github.com/nu774/qaac/pull/28) for a problem that has caused the "--artwork" option of QAAC to not work with LameXP:
http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/Testing/LameXP.qaac-addin.2014-12-25.zip/download

Also see QAAC install instructions in the new LameXP Manual here:
http://lamexp.sourceforge.net/doc/Manual.html#qaac-apple-aac-encoder

Merry Christmas http://www.santatulsa.com/santa-emoticon.gif

I have tested the feature and the artwork is now available.
Thanks

[justonce01]

Would it be possible to get a "portable" version of LameXP?
By portable, I mean that the settings are saved inside the LameXP directory instead of the user/appdata/local folder? Currently, even when you download the ZIP file, the config file gets saved in the appdata folder.

[LoRd_MuldeR]

Would it be possible to get a "portable" version of LameXP?

Reading educates :)

http://lamexp.sourceforge.net/doc/Manual.html#portable-mode

[LoRd_MuldeR]

LameXP v4.11 Beta-13
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-01-01/LameXP-BETA.2015-01-01.Release-Static.Build-1664.exe/download

Changes between v4.10 and v4.11 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-4
* Starting with this version, LameXP is based on the MUtilities library + massive code clean-up
* Updated MediaInfo to v0.7.71 (2014-11-09), compiled with ICL 15.0 and MSVC 12.0
* Updated SoX to v14.4.2-Git (2012-10-06), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus libraries to v1.1.x and Opus-Tools v0.1.9 to latest Git Master (2014-10-04)
* Updated mpg123 decoder to v1.20.1 (2014-06-17), compiled with GCC 4.9.0
* Updated Vorbis encoder to OggEnc v2.87 (2014-06-24), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2014-06-25), using libVorbis v1.3.4
* Updated GnuPG to v1.4.18 (2014-06-30), compiled with GCC 4.9.1
* Fixed potential crash in Cue Sheet importer (occurred when *all* input files were missing)
* Fixed a severe performance bottleneck, especially with a large number of parallel instances
* The limit for the maximum number of parallel instances has been increased to 32
* Experimental support for Windows 10 Technical Preview

http://www.smilies.4-user.de/include/New_Year/neujahr_120.gif

[BoosterPack]

That shouldn't be necessary. So I somehow doubt that this was really the problem!

Again, if your file is rejected for some reason, then I urge you to post some logs and/or MediaInfo reports, so we can figure out what is actually happening...

Here is the report from MediaInfo for a music file that I tried to convert. Only after running LameXP with admin rights was I able to convert this file.

General
Complete name : C:\Users\AAA\Music\The Lord of the Rings - The Rarities Archive\14 - The Return Of The King Trailer.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 12.6 MiB
Duration : 2mn 34s
Overall bit rate mode : Variable
Overall bit rate : 681 Kbps
Album : The Lord Of The Rings – The Rarities Archive
Track name : The Return Of The King Trailer
Performer : Howard Shore
Composer : Howard Shore
Genre : Soundtrack
Recorded date : 2009
FMPS_PLAYCOUNT : 1
FMPS_RATING_AMAROK_SCORE : 0.975

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 2mn 34s
Bit rate mode : Variable
Bit rate : 681 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Stream size : 12.6 MiB (100%)
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)

[LoRd_MuldeR]

I don't see a reason why LameXP should require "admin" rights to open that file. What does the LameXP log (http://lamexp.sourceforge.net/doc/Manual.html#diagnostic-output) say, when you try to open (only) that file without "admin" rights? :confused:

The only reason that I can think of is that the access rights (http://msdn.microsoft.com/en-us/library/windows/desktop/aa374902%28v=vs.85%29.aspx) for this particular file (or the whole directory) are configured in a way that allows "standard" users to see the file (list directory contents), but not to open the file for reading. If the access rights for reading the file are given only the "admin" users, this would explain it. This is possible, but kind of unusual. But then, of course, you also couldn't play that file - unless the player application is running as "admin" too...

[jpsdr]

Stupid question : On your change log of 4.10 to 4.11, you don't mention the update to flac 1.3.1. You don't intend to for now ? Or was it somehow allready done ?

[LoRd_MuldeR]

On your change log of 4.10 to 4.11, you don't mention the update to flac 1.3.1.

Because it has not been updated yet :p

You don't intend to for now ? Or was it somehow allready done ?

I will put that on the "todo" list. I don't consider this a "high priority" for now, because the changes between FLAC 1.3.0 and 1.3.1 are rather small, but I will certainly do it before the next "final" release.

(Aside of a few performance optimizations, the most notable change is the fix of a potential buffer overflow. The latter is the reason why we really should update to FLAC 1.3.1)

[foxyshadis]

Here is the report from MediaInfo for a music file that I tried to convert. Only after running LameXP with admin rights was I able to convert this file.

Did you check where it's converting to? Or whether your music folder has funky permissions (this can happen if you move folders around the disk).

[jpsdr]

but I will certainly do it before the next "final" release.


That's finaly all that matters.
:thanks:

[justonce01]

Reading educates :)

http://lamexp.sourceforge.net/doc/Manual.html#portable-mode

Got it. Thanks.

[Octo-puss]

Would it be possible to add the possibility to add entire folder(s) as a source? I have one huge folder containing the discography of a band I want to encode, and it's very annoying to add each album manually.

[LoRd_MuldeR]

Would it be possible to add the possibility to add entire folder(s) as a source? I have one huge folder containing the discography of a band I want to encode, and it's very annoying to add each album manually.

Try "File" → "Open Folder Recursively" :)

[Octo-puss]

Haha thanks, I didn't think there was any other functionality hidden somewhere in the menus. Could you add it as an extra button though, please?

[LoRd_MuldeR]

Haha thanks, I didn't think there was any other functionality hidden somewhere in the menus. Could you add it as an extra button though, please?

Hmm, I don't think I will add yet another button for this.

[Octo-puss]

Why not? It makes perfect sense. Lots of programs have extra buttons for either selecting a file or an entire folder. Why would I have to go to a menu to do something that is so similar to something else that has its own button? It's not like my arm would fall off by going into a menu instead of clicking on a button, but as you could see, I didn't even think such functionality existed, because the first impression you get from LameXP is that all the functionality is right there in the windows.

[LoRd_MuldeR]

Why not? It makes perfect sense. Lots of programs have extra buttons for either selecting a file or an entire folder. Why would I have to go to a menu to do something that is so similar to something else that has its own button? It's not like my arm would fall off by going into a menu instead of clicking on a button, but as you could see, I didn't even think such functionality existed, because the first impression you get from LameXP is that all the functionality is right there in the windows.

I think the button triple of "Add", "Remove" and "Clear" is good just the way it is. So I don't want to spoil the clarity of the GUI. Adding a second (slightly different) "Add" button would be kind of redundant. Also I believe that adding a whole directory structure recursively is not something that most users need most of the time. And if they ever need it, the "File" menu is the most obvious place to look for something like this. But maybe I'll add a word or two to the manual (http://lamexp.sourceforge.net/doc/Manual.html#tutorial-step-by-step-guide).

[manolito]

XMPlay uses another interesting alternative:
It only has single buttons for adding / removing titles, but if you right-click one of the buttons it deals with whole folders instead of single files. Another possibility would be using Shift-Click for dealing with folders...


Cheers
manolito

[LoRd_MuldeR]

... But maybe I'll add a word or two to the manual (http://lamexp.sourceforge.net/doc/Manual.html#tutorial-step-by-step-guide).

Done.

[schiff1108]

I would like to understand the approach on tags. What tags should get copied from source to output?
In particular I am missing the tags "composer" and "album artist".
When I check the source file with MediaInfo, I do find the tag values as expected. I have made some shots with using Custom Encoding Parameters, but w/o success.

Thanks.

[LoRd_MuldeR]

I would like to understand the approach on tags. What tags should get copied from source to output?
In particular I am missing the tags "composer" and "album artist".
When I check the source file with MediaInfo, I do find the tag values as expected. I have made some shots with using Custom Encoding Parameters, but w/o success.

Meta data is extracted from the original file via MediaInfo. It then will be kept in an internal data structure. And finally it will be re-embedded into the output file, according to the individual encoder's capabilities.

One important thing to understand is that there is not the one standard for meta information! Every file format uses its own eccentric way to keep meta information. Some file formats, like e.g. MP3's "ID3v1" tags, are very limited, with only a few pre-defined fields. With those you can only use the pre-defined fields and that's it. At the same time, some other formats are very flexible, because they store arbitrary key-value pairs. On the one hand, this flexibility is great. But on the other hand, it makes it hard to figure out which keys are actually used practice - and which ones are actually recognized by (most) applications. Therefore "copying" meta information from one file format to another one is not as trivial as you might imagine!

The approach that I took with LameXP is that I designed the internal "meta information" data structure roughly as a "smallest common denominator" for what most file formats offer. This data structure will be filled with the meta tags that MediaInfo brings up. However, not every information that MediaInfo might be able to extract from a specific file format necessarily has an equivalent field in the internal data structure! There are far too many different (obscure) tags that might appear in some file to reserve a field for every single one of them. Instead, our internal data structure is restricted to the most important tags. So it's quite possible that we can not retain every single bit of information that MediaInfo has tracked down!


[EDIT]

Currently, the meta information that can be kept in the internal data structure are as follows:
QString m_titel;
QString m_artist;
QString m_album;
QString m_genre;
QString m_comment;
QString m_containerType;
QString m_containerProfile;
QString m_audioType;
QString m_audioProfile;
QString m_audioVersion;
QString m_audioEncodeLib;
unsigned int m_audioSamplerate;
unsigned int m_audioChannels;
unsigned int m_audioBitdepth;
unsigned int m_audioBitrate;
unsigned int m_audioBitrateMode;
unsigned int m_duration;
unsigned int m_year;
unsigned int m_position;
ArtworkModel m_cover;

[foxyshadis]

Would you consider adding a QMap of unknown and custom tags, that can be re-embedded if the output supports them?

[LoRd_MuldeR]

Would you consider adding a QMap of unknown and custom tags, that can be re-embedded if the output supports them?

I don't think that would solve anything. Of course, with a Map we can maintain arbitrary key-value pairs. That is very flexible, obviously. So we could simply dump everything that MediaInfo brings up into the Map. That's straight forward. But the real challenge here is that, eventually, we need to re-embed all that information into the output file! For example, the LAME encoder accepts a "--tt" switch to specify the "title" of the track and a "--ta" switch to specify the "artist". Thus, I know that if we are using LAME, then I need to pass the value of m_titel via "--tt" switch and the value of m_artist via "--ta" switch. But what to do with the "PhaseOfMoonWhenThisAlbumWasRecorded" entry, if such key appears in the Map? :confused:

[foxyshadis]

I don't think that would solve anything. Of course, with a Map we can maintain arbitrary key-value pairs. That is very flexible, obviously. So we could simply dump everything that MediaInfo brings up into the Map. That's straight forward. But the real challenge here is that, eventually, we need to re-embed all that information into the output file! For example, the LAME encoder accepts a "--tt" switch to specify the "title" of the track and a "--ta" switch to specify the "artist". Thus, I know that if we are using LAME, then I need to pass the value of m_titel via "--tt" switch and the value of m_artist via "--ta" switch. But what to do with the "PhaseOfMoonWhenThisAlbumWasRecorded" entry, if such key appears in the Map? :confused:

Well, if you have Ogg/FLAC or APE tags you just write them back as-is, same if you're going from one id3v2 format to another, just copy everything. (Except encoder and created date tags.) For everything else, map if tags are standardized, drop if not; no one's going to seriously expect to see a PhaseOfMoon tag to end up in mp3. You must already have a map of common entries from one format to another, in the form of the conversions to and from your variables, since id3v2 and Ogg tags are completely different, so it's mostly a matter of extending that with more common tags and allowing arbitrary ones to pass through if possible.

(Album Artist is especially extremely common and part of the default file properties GUI in almost every media player, so that in particular should get special treatment. Even if the Vorbis and id3v2 specs don't mention it, the defacto standard is ALBUMARTIST for the comment tag and TPE2 for id3v2.)

I can try to whip something up if you like, I'm free tomorrow.

[LoRd_MuldeR]

It's not as simple as that, I think. Any solution that is like "if we are going from file format A to file format B then let's do it like this, and if we are going from file format C to file format D then let's do it like that" is not really feasible in practice, because there are way to many possible combinations. Having to implement a special path for each possible combination is no good solution and is hardly extensible. Instead, what we need in practice are solutions that work from any file format to any file format. This, however, requires boiling things down to a "smallest common denominator". And then, of course, not every eccentricity of every file format can be retained. But that's an acceptable trade-off.

For example, the LAME encoder has a dedicated "--ta" switch to set the "artits" of the track. So if the original file had an "artist" tag, we certainly want to pass this via "--ta name" switch, and not via the generic "--tv key=value" switch (introduced with ID3v2.3). Now you could say that we have a few recognized tags that will be passed via dedicated switches and everything else is passed via the generic "--tv" switch. However, what if the original did not have an "artist" tag, but did have a "performer" tag instead? In this case we probably want to pass the value of the "performer" tag to the "--ta" switch, rather than the generic "--tv" switch! Thus, some "smart" mapping of the commonly used tags needs to be implemented.

But we don't want to re-implement this required mapping again and again in every single encoder class! Currently, the required mapping happens at one single point! And that's the FileAnalyzer class. After that, our internal data structure either has a value in its m_artist field, or not. That's a clean design. And the LameEncoder class does not need to care about file format eccentricities, e.g. whether the info originally had been called "artist", "performer" or whatever. LAME simply passes the value of m_artist to the "--ta" param. And that's it! Making the FileAnalyzer class "dumb", by having it dump everything into a Map, would require scattering the actual processing of metainfo among all the Encoder classes - bad code design, IMHO.

[soneca]

It would be very difficult to implement an access to a database to LameXP and thus choose from such information to this database?

[LoRd_MuldeR]

It would be very difficult to implement an access to a database to LameXP and thus choose from such information to this database?

You mean like Gracenote or FreeDB? :confused:

I haven't digged into this topic enough to give a definite answer. I would have to see what kind of API these services offer and whether we can use them 100% free of charges. Somehow they need to "analyze" the audio file in order to be able to determine the meta info. So, if their API requires access to the "raw" (uncompressed) audio data to do the required analysis, it probably wouldn't fit into LameXP. That's because LameXP doesn't actually decompress the input audio files until they are actually converted. And if they require the application to compute some kind of "fingerprint" which is then sent to the web-server for analysis, then it all would depend on how exactly that fingerprint has to be computed...

[soneca]

You mean like Gracenote or FreeDB? :confused:

That's it!
But not to analyze file by file, but the cd's as a whole, the commercial albums.
As the plugin (http://www.cuetools.net/wiki/CTDB_EAC_Plugin) (CTBD) of Cuetools for example.

[LoRd_MuldeR]

LameXP v4.11 Beta-14
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-01-25/LameXP-BETA.2015-01-25.Release-Static.Build-1674.exe/download

Changes between v4.10 and v4.11 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-4
* Starting with this version, LameXP is based on the MUtilities (http://sourceforge.net/p/mutilities/code/) library + massive code clean-up
* Updated MediaInfo to v0.7.72 (2015-01-07), compiled with ICL 15.0 and MSVC 12.0
* Updated SoX to v14.4.2-Git (2012-10-06), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus libraries to v1.1.x and Opus-Tools v0.1.9 to latest Git Master (2014-10-04)
* Updated mpg123 decoder to v1.21.0 (2014-10-11), compiled with GCC 4.9.1
* Updated Vorbis encoder to OggEnc v2.87 (2014-06-24), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2014-06-25), using libVorbis v1.3.4
* Updated FLAC encoder/decoder to v1.3.1 (2014-11-26), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.18 (2014-06-30), compiled with GCC 4.9.1
* Updated QAAC add-in to the latest to QAAC v2.44, including a fix (https://github.com/nu774/qaac/commit/ad1e0ea9daed076531e96cfa3b82f290ba9eeb20) for the --artwork option
* Fixed potential crash in Cue Sheet importer (occurred when all input files were missing)
* Fixed a severe performance bottleneck, especially with a large number of parallel instances
* Fixed a very rare problem that, occasionally, prevented the TEMP folder from being removed
* The limit for the maximum number of parallel instances has been increased to 32
* Experimental support for Windows 10 Technical Preview

[mike20021969]

Is there a new stable round the corner?

[SeeMoreDigital]

Hello,

Microsoft have just released a new version of Win 10 Pro (Build 9926). And now when I run LameXP I see the following: -

http://i62.tinypic.com/30asuaf.png

Sufficed to say, after pressing the 'ok' button, LameXP runs okay...


Cheers

[LoRd_MuldeR]

Microsoft have just released a new version of Win 10 Pro (Build 9926). And now when I run LameXP I see the following

http://www.en.kolobok.us/smiles/big_madhouse/dash2.gif

So, "Windows 7" is 6.1, "Windows 8" is 6.2, "Windows 8.1" is 6.3, but "Windows 10" is... 10.0 - at least in the latest preview build, it appears!

Order #1 for all Microsoft employees:
Invent the most stupid and inconsistent versioning scheme and, once everybody has gotten used to it and has implemented the required workarounds, let's break it once again by making it "sane" all of a sudden :mad:

Anyway, I will fix it for the next build. Also the mixed up title/text in that message box...

Is there a new stable round the corner?

Yes, but there are a few things that I want to address first. Also, my free time is more limited than ever before now. So there is no ETA yet...

[mike20021969]

Yes, but there are a few things that I want to address first. Also, my free time is more limited than ever before now. So there is no ETA yet...

No worries. Thanks.

:thanks:

[Dogway]

After a year your program becomes a PITA, showing a warning that I need to update, a stupid music sounds, and 10 seconds of my life down the drain.

Pair that with the (again) stupid decision of auto-labeling the output files, and you start to wonder if programmers want to ease your life or make it more complicated.

I leave this here so people know what to abide by. I think I am going back to a version prior to this "feature" (if there was one).

[manolito]

After a year your program becomes a PITA, showing a warning that I need to update, a stupid music sounds, and 10 seconds of my life down the drain.

I have to agree... :p

LameXP has an option to deactivate all update reminders. When I have selected this option then I really really do not want to be reminded for updates, even after more than a year.


Cheers
manolito

[LoRd_MuldeR]

After a year your program becomes a PITA, showing a warning that I need to update, a stupid music sounds, and 10 seconds of my life down the drain.

Pair that with the (again) stupid decision of auto-labeling the output files, and you start to wonder if programmers want to ease your life or make it more complicated.

I leave this here so people know what to abide by. I think I am going back to a version prior to this "feature" (if there was one).

Sigh. Yes, if (and only if) you have not updated the program for more than a whole year, then the update reminder becomes little more emphatic. And that is intentionally! People tend to be lazy when it comes to updates, so a little "motivation" is needed. If you really think that spending three minutes for updating the program once per year is asking too much - and let's not forget that the user interaction required during the update process is next to nothing - then I'm out of ideas.

Why would you want to stick with a version that is more than year old? During this year a lot of effort has been made to further improve the program. Why do you want to ignore all these efforts? If there is any understandable reason to stick with an outdated version, then it would be regressions in the current version. But, in that case, I highly recommend that you report the regressions which you have encountered, so that we can (hopefully) sort them out ASAP.

Last but not least, remember that is FOSS (http://de.wikipedia.org/wiki/Free/Libre_Open_Source_Software). So if you REALLY wanted to permanently stick with an old version for whatever reason, or should development ever be discontinued (which I currently have no plans for!), then you could simply remove the update reminder from the source code. I won't give you any specifics (and I beg others to not do this either!), but the required change would be minimal. Even with rudimentary programming skills you could figure this out in a minute or so.


(Addendum: There are various "freeware" sites out there, which are still distributing versions of my software that are many years old! These versions don't represent the current development state of the software at all and I don't want people to get the wrong impression. Consequently, we need to make sure that even those people, which happen to stumble upon an extremely old version of the program, will quickly be "upgraded" to a somewhat recent version)

[SeeMoreDigital]

Jeez...

Don't you just love people who moan about 'free-ware' software. Yep, you just want to get-out there and give them all a big squishy hug... Yep, you really do!

[Dogway]

Thanks this is not a dictatorship and I can voice my opinion : )
That's why I will state the same words in the videohelp review comments. You @SeeMoreDigital are free to like or dislike them, but I will just say, this is the first time in my life a program insists on updating so annoyingly. I'm sorry for not being in the OCD update spiral, some people simply know when enough is good enough.

[LoRd_MuldeR]

You are free to express your opinion. But I think you are way exaggerating things here. You still haven't explained what exactly you are complaining about: Why are you refusing to update to a somewhat reason version so eagerly? I assume that it can not be because the update process takes too long or because it is too much complicated - this can almost certainly be excluded. So it leaves two options: Either you want to stick with the deprecated version, because the new version has some problem that didn't exist in the old version, or you are complaining for purely "ideological" reasons. In the former case, I suggest you report the problem, so we (hopefully) can sort it out. In the latter case there is no way to make it right for you.

BTW: It is perfectly normal that software products will reach "end of life" after a certain period, at which point an update to a recent version is obligatory. Only that with most commercial products you'll have to pay to get an up-to-date version, while LameXP is free software and thus the update is offered to you 100% free of charge. Most people know how to appreciate this service.

[Dogway]

"so we can...", mandatory updates, EOL, 100% free of charge, service... isn't that a bit of megalomaniac? There's more than black or white, it's for both reasons, and I wrote them as a review in VideoHelp. I'm not going to ask or bug report (complain in you vocabulary) anything anymore after the way I was treated here before (censored and banned). I haven't seen you give in a single thing anyone told you in this thread, that speaks for itself.

I came only to let people know about the infamous 1 year update reminder.
At least and surprisingly is open-source, so that's something.

[LoRd_MuldeR]

"so we can...", mandatory updates, EOL, 100% free of charge, service... isn't that a bit of megalomaniac?

Yeah, developing a software in your free time over a period of 10+ years and offering that software to everybody 100% free of charge is... megalomaniac :rolleyes:

(If somebody offers free vanilla ice to you on a hot summer day, you are probably going to complain that you like chocolate better and ask why that moron does not offer chocolate ice for free)

I came only to let people know about the infamous 1 year update reminder.
At least and surprisingly is open-source, so that's something.

You are complaining about something that only happens under extremely rare circumstances, i.e. when somebody really hasn't update the software for more than a whole year. Something that a responsible-minded user, who at least makes some effort to keep his software up-to-date, is never going to see. And, despite all of this, you a trying make it sound as if it was such a "big" affair - while in fact it's barely worth mentioning. Finally, you haven't been able to give any kind of explanation why in the world you are so eagerly refusing to update to a somewhat recent version. Consequently, I'm just going to take this for what it is: Complaining as a pastime, with no honest interest in resolving or improving anything.

(Telling the world that this software is going to remind you that you haven't updated your software for more than a whole year, iff indeed you haven't updated your software for more than a whole year, is like announcing that the sky is blue)

[Dogway]

You seem to ignore the fact that a program update, like new programs can be "game changers". That in a production environment is consumed time (for learning the new rules), and that equals to money. Maybe NASA prefers using DOS based OS, banks are content with XP, and some users are fine using a certain program build because they have no time to update the 200 programs they have on their computer, or simply fits their necessities.
You don't have to make a fuss of it, I came here, voiced my opinion, over. There's no more to it. Learn to accept critics, or opinions ("complains" in your vocabulary).

[LoRd_MuldeR]

You are not criticizing anything, that's the problem! When asked why exactly you eagerly want to stick with the old outdated version and/or what problems are preventing you from using the up-to-date version, you are not delivering any explanations whatsoever. Thus I have to assume that you haven't even tried the new version. So you are obviously not interested in getting any real problems fixed, because you have not encountered any real problem. Instead, you are complaining that the program is reminding you that you missed updating the program for more than a whole year, when indeed you missed updating the program for more than a whole year. This is like hurting yourself with a hammer and then complaining that it hurts! :rolleyes:

So either report a real problem, make a constructive suggestion, or stop flooding this thread...

[foxyshadis]

Given the amount of choice in open source audio apps, the easiest solution to disliking a developer's personal style is to use another. It should be obvious by now that arguing about unusual design decisions won't ever change Mulder's mind, and that's a general truism for any single-developer software, no matter how right you think you are. It's their baby, after all.

Move on, let it go, you literally can't win.

[LoRd_MuldeR]

It should be obvious by now that arguing about unusual design decisions won't ever change Mulder's mind, and that's a general truism for any single-developer software, no matter how right you think you are. It's their baby, after all.

Move on, let it go, you literally can't win.

:rolleyes:

To make it clear: It's perfectly okay, if somebody expresses a different opinion. And if he/she has convincing arguments, I have no problem with accepting suggestions, as it has happened so many times before. But it definitely is not acceptable, if somebody comes along and proclaims what is "wrong" in my software, as if his opinion was a fact (which it is not!), or what I ought to change in my software, as if he was my boss (which he is not!). Furthermore, if he actually came here with goal to improve the software (not just for ranting), he would try convince me. And you convince people with convincing arguments. You do not convince people by repeating the same complaints over and over again, while refusing to provide any details. You do not convince people by ignoring explanations that have been given to you. And you certainly do not convince people by blackmail ("either you do what I want or I'm going to spread defamation about your software"). More than enough said.

[LoRd_MuldeR]

LameXP v4.11 RC-1
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-02-17/LameXP-RC1.2015-02-17.Release-Static.Build-1678.exe/download

Changes between v4.10 and v4.11 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-4
* Updated Qt runtime libraries to v4.8.7 snapshot-4 (2015-02-16), compiled with MSVC 12.0
* Starting with this version, LameXP is based on the MUtilities library + massive code clean-up
* Updated MediaInfo to v0.7.72 (2015-01-07), compiled with ICL 15.0 and MSVC 12.0
* Updated SoX to v14.4.2-Git (2012-10-06), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus libraries to v1.1.x and Opus-Tools v0.1.9 to latest Git Master (2014-10-04)
* Updated mpg123 decoder to v1.21.0 (2014-10-11), compiled with GCC 4.9.1
* Updated Vorbis encoder to OggEnc v2.87 (2014-06-24), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2014-06-25), using libVorbis v1.3.4
* Updated FLAC encoder/decoder to v1.3.1 (2014-11-26), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.18 (2014-06-30), compiled with GCC 4.9.1
* Updated QAAC add-in to the latest to QAAC v2.44, including a fix for the --artwork option
* Fixed potential crash in Cue Sheet importer (occurred when all input files were missing)
* Fixed a severe performance bottleneck, especially with a large number of parallel instances
* Fixed a very rare problem that, occasionally, prevented the TEMP folder from being removed
* The limit for the maximum number of parallel instances has been increased to 32
* Experimental support for Windows 10 Technical Preview

[SeeMoreDigital]

I'm happy to report that this version launches without any errors using Win 10 Pro (Build 9926) :)

[kadajawi]

Question: I want to convert the soundtrack of TV episodes into Opus, and they are in surround. The way I understand it the bitrate setting you use for Opus in LameXP is the overall bitrate... at which point having 256 kbit as the maximum is a bit low for 6 channels...? Any way to go higher?

[LoRd_MuldeR]

Question: I want to convert the soundtrack of TV episodes into Opus, and they are in surround. The way I understand it the bitrate setting you use for Opus in LameXP is the overall bitrate... at which point having 256 kbit as the maximum is a bit low for 6 channels...? Any way to go higher?

It's not currently possible. But I could allow for even higher Opus bitrate in future versions, if there actually is demand for it.

(BTW: Did you actually try 256 kbps for your source and result was not satisfying?)

[kadajawi]

It's not currently possible. But I could allow for even higher Opus bitrate in future versions, if there actually is demand for it.

(BTW: Did you actually try 256 kbps for your source and result was not satisfying?)

For multichannel content that would be nice. Currently I get around 40 kbit per channel, and that is too little. The same source with Ogg Vorbis q4 is around 380 kbit in total, and that's the quality I want. I could hear some artifacts, and that was on cheap speakers. I think with 320 kbit it should be fine, but 256 is too low IMHO. And imagine what happens with 7.2 audio sources...

[SeeMoreDigital]

For multichannel content that would be nice. Currently I get around 40 kbit per channel, and that is too little. The same source with Ogg Vorbis q4 is around 380 kbit in total, and that's the quality I want. I could hear some artifacts, and that was on cheap speakers. I think with 320 kbit it should be fine, but 256 is too low IMHO. And imagine what happens with 7.2 audio sources...With regard to 5.1 channel encodes. Have you tried using HE-AAC between 192Kbps and 256Kbps?

[GMJCZP]

LoRd_MuldeR, for CD ripping you recommend CUE Tools, Does the program fre:ac is equivalent? Thanks.

[LoRd_MuldeR]

LoRd_MuldeR, for CD ripping you recommend CUE Tools
Do I? :confused:

Actually I use Exact Audio Copy (EAC) when I need to rip one of my Audio-CD's.

Does the program fre:ac is equivalent? Thanks.
Since I don't use fre:ac, so I cannot say much about it.

But since it's a fully-fledged audio converter, I guess you would use either LameXP or fre:ac. You probably wouldn't use fre:ac for ripping your Audio-CD just to convert with LameXP afterwards ;)

Anyway, whether the "ripping" capabilities of fre:ac are on par with EAC, I have no idea...

[GMJCZP]

Do I? :confused:

Actually I use Exact Audio Copy (EAC) when I need to rip one of my Audio-CD's.


Sorry for my confusion, it was EAC and not Cue Tools, lol.
Thanks for your reply LoRd_MuldeR.

I know this question is already out of the post, but someone will clarify whether fre:ac is usable as EAC or Cue Tools for CD ripping?

[LoRd_MuldeR]

I know this question is already out of the post, but someone will clarify whether fre:ac is usable as EAC or Cue Tools for CD ripping?

I don't know whether fre:ac uses any "external" program (or a specific library) for Audio CD ripping or whether it does this all by itself.

You probably want to ask the fre:ac author ;)

[soneca]

Sorry for my confusion, it was EAC and not Cue Tools, lol.
Thanks for your reply LoRd_MuldeR.

I know this question is already out of the post, but someone will clarify whether fre:ac is usable as EAC or Cue Tools for CD ripping?

If you want to extract also CDs scratched, those who are not in good condition recommend using programs like EAC, dBpoweramp and CUERipper to use secure mode to check and try to correct the errors and also extra verification by AccurateRip.
fre:ac would be more appropriate only for conversion between formats.

[SeeMoreDigital]

Oh no... My binary has expired... It's the end of the world :eek:

[lethedoom]

Mine Too. Back to still reliable 4.10 final until further development of 4.11 is made available.

[Przemek_Sperling]

Amen, brother, amen.

[Andouille]

Oh no... My binary has expired... It's the end of the world :eek:

Mine has expired 5 years ago (v3.18)...
I just have to click "OK" two times more and it works...

[LoRd_MuldeR]

Oh no... My binary has expired... It's the end of the world :eek:

Sorry, usually I will upload a new test build before the previous test build has expired.

However, this week I have been on a business trip, so no access to my development machine, ultra-slow hotel Internet connection, and no time anyway.

New build will be available soon, but I'll need to catch a snatch of sleep now ;)

[Przemek_Sperling]

So sleep well :-)

[LoRd_MuldeR]

LameXP v4.11 RC-3

Changes between v4.10 and v4.11 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-4
* Starting with this version, LameXP is based on the MUtilities (http://sourceforge.net/p/mutilities/code/) library + massive code clean-up
* Added support for the DynamicAudioNormalizer (https://github.com/lordmulder/DynamicAudioNormalizer) normalization filter
* Updated Qt runtime libraries to v4.8.7 snapshot-4 (2015-02-16), compiled with MSVC 12.0
* Updated MediaInfo to v0.7.72 (2015-01-07), compiled with ICL 15.0 and MSVC 12.0
* Updated SoX to v14.4.2-Final (2015-02-22), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus libraries to v1.1.x and Opus-Tools v0.1.9 to latest Git Master (2014-10-04)
* Updated mpg123 decoder to v1.22.0 (2015-02-24), compiled with GCC 4.9.2
* Updated Vorbis encoder to OggEnc v2.87 (2014-06-24), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2014-06-25), using libVorbis v1.3.4
* Updated FLAC encoder/decoder to v1.3.1 (2014-11-26), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.18 (2014-06-30), compiled with GCC 4.9.1
* Updated QAAC add-in to the latest to QAAC v2.44, including a fix for the --artwork option
* Fixed potential crash in Cue Sheet importer (occurred when all input files were missing)
* Fixed a severe performance bottleneck, especially with a large number of parallel instances
* Fixed a very rare problem that, occasionally, prevented the TEMP folder from being removed
* The limit for the maximum number of parallel instances has been increased to 32
* Experimental support for Windows 10 Technical Preview
* Updated language files (big thank-you to all contributors !!!)

[SeeMoreDigital]

Woohoo! The world is re-born :D

[manolito]

Thanks very much for the RC3 version... :thanks:

Did a couple of tests (still my old WinXP on a non-SSE2 CPU), and I found only one bug. :devil:

The latest LameXP.qaac-addin.2014-01-19.zip does not work with the current Apple Application Support version. The AAC encoder is simply not recognized. It is necessary to use a newer qaac.exe version in the LameXP folder, the version from this archive does work:
https://yadi.sk/d/IaHUQp7wen9uX

Otherwise no problems at all, special thanks for still supporting my CPU (of course still need to switch to 16 bit colors).

And even the patched SoX version with integrated DynamicAudioNormalizer does not require SSE2 (as opposed to the version which ships with DynamicAudioNormalizer), much appreciated... :)

I also like the revamped audio normalizing setup, the channel coupling option is much more intuitive than the former method.


Thanks again,
Cheers
manolito

[LoRd_MuldeR]

The latest LameXP.qaac-addin.2014-01-19.zip does not work with the current Apple Application Support version. The AAC encoder is simply not recognized. It is necessary to use a newer qaac.exe version in the LameXP folder, the version from this archive does work:
https://yadi.sk/d/IaHUQp7wen9uX

Interesting ;)

I had a quick look at QAAC changelog and could not find a change (since the 2014-12-25 (http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/Testing/LameXP.qaac-addin.2014-12-25.zip/download) build) that explicitly addresses Apple Application Support compatibility:
https://github.com/nu774/qaac/commits/master

Anyway, I can try to make a fresh QAAC build from Git Master and we can check if that helps.

BTW: What version of Apple Application Support are you using and how can I get it? What is the newest version that still works with "my" QAAC binary?

[manolito]

BTW: What version of Apple Application Support are you using and how can I get it? What is the newest version that still works with "my" QAAC binary?

I used the current version 2.3.6 dated from 07.10.2014. I extracted it from the current QuickTime installer.

I normally do not use Apple Application Support because it is a little too snoopy for my taste. I use portable qaac versions instead like the one from my link. But for testing the latest LameXP version I cleaned up everything and installed the qaac addon and Apple Application Support exactly like explained in the manual. And I only got it to work after replacing qaac.exe with the newer version.


Cheers
manolito

[LoRd_MuldeR]

I used the current version 2.3.6 dated from 07.10.2014. I extracted it from the current QuickTime installer.

I tried with Apple Application Support version 3.1.2 (containing CoreAudioToolbox version 7.9.9.6) and it worked fine for me with latest QAAC Add-in for LameXP (2014-12-25) :confused:

Apple Application Support → https://www.sendspace.com/file/njfor9
QAAC Add-in for LameXP → http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/Deprecated/LameXP.qaac-addin.2014-12-25.zip/download


Anyway, I am going to make a build of the the latest QAAC version now, just to be sure we aren't missing anything...

[LoRd_MuldeR]

Updated QAAC Add-in for LameXP, based on QAAC v2.47 (2014-02-15)
http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/Testing/LameXP.qaac-addin.2015-03-22.zip/download

[LoRd_MuldeR]

LameXP v4.11 RC-4

Changes between v4.10 and v4.11 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-4
* Starting with this version, LameXP is based on the MUtilities (http://sourceforge.net/p/mutilities/code/) library + massive code clean-up
* Added support for the DynamicAudioNormalizer (https://github.com/lordmulder/DynamicAudioNormalizer) normalization filter
* Updated Qt runtime libraries to v4.8.7 snapshot-4 (2015-02-16), compiled with MSVC 12.0
* Updated MediaInfo to v0.7.72 (2015-01-07), compiled with ICL 15.0 and MSVC 12.0
* Updated SoX to v14.4.2-Final (2015-02-22), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus libraries to v1.1.x and Opus-Tools v0.1.9 to latest Git Master (2015-03-26)
* Updated mpg123 decoder to v1.22.0 (2015-02-24), compiled with GCC 4.9.2
* Updated Vorbis encoder to OggEnc v2.87 (2014-06-24), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2014-06-25), using libVorbis v1.3.4
* Updated FLAC encoder/decoder to v1.3.1 (2014-11-26), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.18 (2014-06-30), compiled with GCC 4.9.1
* Updated QAAC add-in to the latest to QAAC v2.44, including a fix for the --artwork option
* Fixed potential crash in Cue Sheet importer (occurred when all input files were missing)
* Fixed a severe performance bottleneck, especially with a large number of parallel instances
* Fixed a very rare problem that, occasionally, prevented the TEMP folder from being removed
* The limit for the maximum number of parallel instances has been increased to 32
* Experimental support for Windows 10 Technical Preview
* Updated language files (big thank-you to all contributors !!!)

[LoRd_MuldeR]

LameXP v4.11 has been released :)
https://github.com/lordmulder/LameXP/releases/latest

Changes between v4.10 and v4.11 [2015-04-05]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-4
* Starting with this version, LameXP is based on the MUtilities (http://sourceforge.net/p/mutilities/code/) library + massive code clean-up
* Added support for the DynamicAudioNormalizer (https://github.com/lordmulder/DynamicAudioNormalizer) normalization filter
* Updated Qt runtime libraries to v4.8.7 snapshot-5 (2015-03-25), compiled with MSVC 12.0
* Updated MediaInfo to v0.7.72 (2015-01-07), compiled with ICL 15.0 and MSVC 12.0
* Updated SoX to v14.4.2-Final (2015-02-22), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus libraries to v1.1.x and Opus-Tools v0.1.9 to latest Git Master (2015-03-26)
* Updated mpg123 decoder to v1.22.0 (2015-02-24), compiled with GCC 4.9.2
* Updated Vorbis encoder to OggEnc v2.87 (2014-07-03), using libvorbis v1.3.4 and aoTuV b6.03_2014
* Updated Vorbis decoder to OggDec v1.10.1 (2015-03-19), using libVorbis v1.3.5
* Updated FLAC encoder/decoder to v1.3.1 (2014-11-26), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.18 (2014-06-30), compiled with GCC 4.9.1
* Updated QAAC add-in (http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/) to the latest to QAAC v2.44, including a fix (https://github.com/nu774/qaac/commit/ad1e0ea9daed076531e96cfa3b82f290ba9eeb20) for the --artwork option
* Fixed potential crash in Cue Sheet importer (occurred when all input files were missing)
* Fixed a severe performance bottleneck, especially with a large number of parallel instances
* Fixed a very rare problem that, occasionally, prevented the TEMP folder from being removed
* The limit for the maximum number of parallel instances has been increased to 32
* Experimental support for Windows 10 Technical Preview
* Updated language files (big thank-you to all contributors !!!)

http://fc03.deviantart.net/fs71/f/2011/113/c/5/hoppy_easter_sign_by_mirz123-d3eojnl.gif

[Sparktank]

Thanks for the update, quite busy!

Happy Easter to you too.

[Octo-puss]

Can I get the standalone version like before please?

[Przemek_Sperling]

Thank you very much. Great job!

[LoRd_MuldeR]

Can I get the standalone version like before please?

I assume with "standalone version" you mean a binary that has portable mode (http://lamexp.sourceforge.net/doc/Manual.html#portable-mode) enabled by default ;)

Well, here we go:
http://sourceforge.net/projects/lamexp/files/Miscellaneous/Special%20Builds/LameXP-PORTABLE.2015-04-05.Release-Static.Build-1700.zip/download

[soneca]

Thanks for the new version!

[jpsdr]

Thanks for your work.
I've noticed a minor issue (unless it's wanted or i misunderstand the purpose of display), it probably exists since a long time.
I have an i7@980 with 6 cores with HT.
But, after install, and "Choose based on core" is checked, the cursor is on 4 (when i would expect 6 in that case).
Is it normal ?

[Octo-puss]

I assume with "standalone version" you mean a binary that has portable mode (http://lamexp.sourceforge.net/doc/Manual.html#portable-mode) enabled by default ;)

Well, here we go:
http://sourceforge.net/projects/lamexp/files/Miscellaneous/Special%20Builds/LameXP-PORTABLE.2015-04-05.Release-Static.Build-1700.zip/download
Uh, yes. Thank you. Been a while so I forgot what was it called :D

[LoRd_MuldeR]

But, after install, and "Choose based on core" is checked, the cursor is on 4 (when i would expect 6 in that case).
Is it normal ?

It's perfectly normal. As long as you keep "Choose [...] based on the number of CPU cores" checked, the slider doesn't apply and it can be ignored altogether :)

The slider currently defaults to 4, yes. But that is completely unrelated to the number of parallel threads that will be used if you let the program decide.

Also note that the heuristic, which is used to automatically decide the number of parallel threads (based on the number of CPU's), is not a simple "1:1" mapping.

Looks more like this:
http://i.imgur.com/YnQAvU5.png

[TOM_SK]

Anyone else getting this error on Windows 8?

http://i.imgur.com/6TtrPLW.png

[LoRd_MuldeR]

Anyone else getting this error on Windows 8?

http://i.imgur.com/6TtrPLW.png

Nope, works perfectly fine on my Windows 8.1 machine:
http://i.imgur.com/AqXWCkh.jpg

Is this problem reproducible? If so, what are your system specifications? Does the debug console (http://lamexp.sourceforge.net/doc/Manual.html#options-for-debugging) show any helpful info?

[manolito]

@ TOM_SK

Ha, the guru strikes again...

Just for the fun of it, can you try to change your display color depth from 32bit to 16bit and see what happens?

The reason I ask is that on my machine LameXP only works with 16bit colors, with 32bit colors I get exactly this error.


Cheers
manolito

[LoRd_MuldeR]

Just for the fun of it, can you try to change your display color depth from 32bit to 16bit and see what happens?

That doesn't seem to be possible any longer on Windows 8.

The reason I ask is that on my machine LameXP only works with 16bit colors, with 32bit colors I get exactly this error.

"Exactly this error" doesn't say anything here, though. That's because the unhandeled exception handler will be invoked, well, when the system throws some unexpected exception.

And this can be virtually anything! Like an access violation, a division by zero, an illegal instruction or whatever. We won't know without further details...


Here is a new Debug build, which might provide some insight on what's going on:
http://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-TEST.2015-04-06.DEBUG.Build-1700.exe/download

Please use the Windows Debugger (WinDbg) for creating a proper stack trace:
https://www.sendspace.com/file/xepka0

[soneca]

Thanks for your work.
I've noticed a minor issue (unless it's wanted or i misunderstand the purpose of display), it probably exists since a long time.
I have an i7@980 with 6 cores with HT.
But, after install, and "Choose based on core" is checked, the cursor is on 4 (when i would expect 6 in that case).
Is it normal ?

Here using the i7 980X got a good difference between the two modes.
Converting 85 songs flac to mp3 VBR/quality level 1/algorithm-better quality.
61 seconds based on core and 50 seconds using 12 cores(HT).
And much faster than version 4.10, seems to have a better use of the instances.:cool:

[manolito]

Minor point about latest version:

The FAQ.html file needs to be updated. For the qaac addon it still links to the deprecated version from January 2014. The Manual.html file has the correct links...


Cheers
manolito

[LoRd_MuldeR]

And much faster than version 4.10, seems to have a better use of the instances.:cool:

Yes, a bug that could cause undesired delays in the creation of new encoder instances has been fixed with this version. This is especially noticeable, if you run a large number of instances in parallel.

http://i.imgbox.com/3G4Zr9xT.png (https://vimeo.com/114437958)


The FAQ.html file needs to be updated. For the qaac addon it still links to the deprecated version from January 2014. The Manual.html file has the correct links...

The old FAQ document has been deprecated, in favor of the new manual. It will be removed in a future version.

(There's also an FAQ section in the new manual file)

[soneca]

A huge difference! ;)

http://s20.postimg.org/mddd89bwt/Lame_xp_4_10.png
http://s20.postimg.org/o6g9wkx3h/Lame_xp_4_11.png

[manolito]

The old FAQ document has been deprecated, in favor of the new manual. It will be removed in a future version.

Does this also mean that the Fraunhofer AAC encoder is no longer supported?


Cheers
manolito


P.S.
A little bit Off-Topic...
The latest SoX downloads 14.4.2 at SourceForge only offer dynamic versions containing dozens of library DLLs. (The previous version 14.4.1 war almost static, only 2 additional DLLs required). Now the current LameXP version contains a patched SoX version 14.4.2 which not only has DynamicAudioNormalizer built in, but it also is absolutely static, no separate DLLs required. Great! Can I use this version to replace SoX in my plugins, or are there any catches?

[LoRd_MuldeR]

Does this also mean that the Fraunhofer AAC encoder is no longer supported?

It's supposed to still work, but haven't used it for a long time. There haven't been any updates either.

Does anybody use that encoder nowadays, given that people generally seems to favor QAAC and given that Winamp (where the encoder DLL was taken from) is gone for good?

The latest SoX downloads 14.4.2 at SourceForge only offer dynamic versions containing dozens of library DLLs. (The previous version 14.4.1 war almost static, only 2 additional DLLs required). Now the current LameXP version contains a patched SoX version 14.4.2 which not only has DynamicAudioNormalizer built in, but it also is absolutely static, no separate DLLs required. Great! Can I use this version to replace SoX in my plugins, or are there any catches?

SoX can be built with a zillion of optional libraries. I guess the "official" Windows binaries have these optional dependencies included, as shared libraries (DLL files).

My binary is kind of a "minimal" build, with all the optional lib's disabled. That's because I don't use SoX for encoding/decoding or for other fancy stuff. If you don't mind about a few missing optional features, there's nothing to worry.

(BTW: Also some of the libraries included with the official SoX binaries are specific to MinGW. My binary is created with MSVC/ICL, and with the static C++ Runtime)

[manolito]

To get Qaac working with LameXP the manual explains that the Apple Application Support must be installed. While this is much better than installing QuickTime or iTunes, it is still a little bulky and it installs a couple of services, and it calls home frequently.

Luckily there is a way to avoid the installation of Apple Application Support, this is how it is done:

7-Zip is required (anyone who has not installed it?)
Download the latest iTunes or QuickTime installer from Apple
Download "MakePortable.zip" from the Qaac project page:
https://sites.google.com/site/qaacpage/cabinet

Put the Apple installer and MakePortable.cmd into the same folder and run Makeportable.cmd.

You will end up with a newly created subfolder "QTFiles". Move this subfolder to your LameXP folder (i.e. make a subfolder below the main LameXP folder).

Of course you still need to copy the files from the Qaac add-on into your LameXP main folder.



Cheers
manolito

[LoRd_MuldeR]

Yeah, I know about this method, but didn't want to make the install instructions more complex than they are already.

Anyway, I added a link to the manual now ;)

[LoRd_MuldeR]

LameXP v4.12 Alpha-4

Changes between v4.11 and v4.12 [unreleased]:
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expressions engine
* Updated MediaInfo to v0.7.73 (2015-04-09), compiled with ICL 15.0 and MSVC 12.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore

[SeeMoreDigital]

Changes between v4.11 and v4.12 [unreleased]:
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774

Nice one... Out of interest, where can the necessary 'FdkAacEnc encoder binaries' be found?

[manolito]

You have to make the binary yourself using the file fdkaac_autobuild.zip from here:
https://sites.google.com/site/qaacpage/cabinet


Cheers
manolito

[LoRd_MuldeR]

LameXP v4.12 Alpha-6
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-05-25/

Changes between v4.11 and v4.12 [unreleased]:
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated MediaInfo to v0.7.73 (2015-04-09), compiled with ICL 15.0 and MSVC 12.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore

[Motenai Yoda]

If I'm not wrong qaac doesn't support hev2 profile.
Indeed LameXP don't add any switch.

anyway fdkaac vbr modes are 1-5 but is selectable only up to 4 (5 did has a bug on >64kHz input, but seems it's fixed in 0.1.4 as changelog said "Fix VBR encoding of sample rates over 64 kHz")

any way to add normalization like TruePeak/EBU R128/ITU-R BS.1770?
basically
The stages of processing are:
1 Attenuate: 12.04 dB attenuation
2 4 × over-sampling
3 Low-pass filter
4 Absolute: Absolute value
source: https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-I!!PDF-E.pdf

where
- 1 "The purpose of this step
is to provide headroom for the subsequent signal processing employing integer arithmetic."
- 2 and 3 are a simple resampling to at least 192kHz (fill with 0 then lowpass with a FIR filter)
- 4 as ever get the max peak's abs value. (then add +12.04dB I think)

should can be easely done with sox

[LoRd_MuldeR]

If I'm not wrong qaac doesn't support hev2 profile.
Indeed LameXP don't add any switch.

I think the Apple AAC encoder doesn't support HEv2 profile. So QAAC doesn't. So LameXP doesn't (when using QAAC).

anyway fdkaac vbr modes are 1-5 but is selectable only up to 4 (5 did has a bug on >64kHz input, but seems it's fixed in 0.1.4 as changelog said "Fix VBR encoding of sample rates over 64 kHz")

Should be fixed:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-05-29/LameXP-ALPHA.2015-05-29.Release-Static.Build-1756.exe/download

should can be easely done with sox

Can it be done with a single SoX invocation? If so, what is the exact SoX command-line that performs the required operations?

[Motenai Yoda]

I think the Apple AAC encoder doesn't support HEv2 profile. So QAAC doesn't. So LameXP doesn't (when using QAAC).
but is selectable and doesn't give any prompt/warn nor fallback to HE

Can it be done with a single SoX invocation? If so, what is the exact SoX command-line that performs the required operations?
I will investigate Sir:

ie gain -12.04 rate -v -s 192k gain -n *NormalizationLevel* rate -v -s *OriginalSampleRate* (dither?)

or gain -12.04 upsample *UpsampleFactor* fir *FirCoeff_Table_File* stat (should print some stuff, peak value included)

*/surely neither works but I'm too tired now to quarrel with sox/*

paper saids that UpsampleFactor should give at least 192kHz so ie 4 for 48kHz sources, 2 for 96kHz ones

fir coeffs
0.0017089843750 −0.0291748046875 −0.0189208984375 −0.0083007812500
0.0109863281250 0.0292968750000 0.0330810546875 0.0148925781250
−0.0196533203125 −0.0517578125000 −0.0582275390625 −0.0266113281250
0.0332031250000 0.0891113281250 0.1015625000000 0.0476074218750
−0.0594482421875 −0.1665039062500 −0.2003173828125 −0.1022949218750
0.1373291015625 0.4650878906250 0.7797851562500 0.9721679687500
0.9721679687500 0.7797851562500 0.4650878906250 0.1373291015625
−0.1022949218750 −0.2003173828125 −0.1665039062500 −0.0594482421875
0.0476074218750 0.1015625000000 0.0891113281250 0.0332031250000
−0.0266113281250 −0.0582275390625 −0.0517578125000 −0.0196533203125
0.0148925781250 0.0330810546875 0.0292968750000 0.0109863281250
−0.0083007812500 −0.0189208984375 −0.0291748046875 0.0017089843750

Note fdkaac from jb-alvarado/wiiaboo's media-autobuild_suite can be used too (since today XD)

[LoRd_MuldeR]

but is selectable and doesn't give any prompt/warn nor fallback to HE

Yes, because other AAC encoders supported in LameXP do support HEv2 profile just fine, so the option needs to reflect this.

In theory we could show a warning, if a specific AAC profile is selected, but the current AAC encoder doesn't support it. But I'm not sure we need this extra complexity.

Fallback to HE-AAC is implemented for QAAC already. But this works for CBR/ABR modes modes only, so in VBR mode you always get LC-AAC.

qaac 2.47
Usage: qaac [options] infiles....

--he HE AAC mode (TVBR is not available)


I will investigate Sir:

surely neither works but I'm too tired now to quarrel with sox

Well, it seems somebody has already implemented EBU R128 normalization, based on SoX/FFmpeg:
http://r128gain.sourceforge.net/

Unfortunately this tool requires SoX and FFmpeg as separate libraries. This makes it a bit awkward for integration into LameXP.

[manolito]

R128Gain has been superseded by BS1770Gain which is more universal (but no GUI). The necessary ffmpeg and SoX libraries are stripped down to the absolute minimum (5 DLLs, but still 15 MB).

For integration into LameXP it would probably make more sense to just use a current version of ffmpeg.exe for the EBU detection pass. The following command displays the detected loudness values which can be intercepted. The necessary correction can be done using the SoX library which comes with LameXP.

ffmpeg.exe -nostats -i %1 -filter_complex ebur128 -f null -

Keep in mind that just applying EBU loudness correction does not offer any safeguards against clipping...


Cheers
manolito


//EDIT//
The original R128Gain software allows to use ffmpeg and SoX libraries which are already present on the HDD:

--ffmpeg=<path> Directory of the FFmpeg shared libraries.
--sox=<path> Directory of the SoX shared libraries.
--lame=<path> Directory of the Lame shared libraries.
--magick=<path> Directory of the ImageMagick shared libraries.

[Motenai Yoda]

Even with ffmpeg only,without sox.
btw is -filter_complex "ebur128=peak=true"

I will investigate Sir:
surely neither works but I'm too tired now to quarrel with sox
Well, it seems somebody has already implemented EBU R128 normalization, based on SoX/FFmpeg:
http://r128gain.sourceforge.net/
I was sarcastic.

sox.exe %1 %1_out.wav gain -12.04 rate -v -s 192k gain -n -1 rate -v -s 44100
seems to work, normalizing at -1.0 -> -1.3 (maybe rate with -v -s is overkill)


sox.exe %1 -n gain -12.04 rate -v -s 192k stats
Overall Left Right
DC offset 0.000004 0.000003 0.000004
Min level -0.259104 -0.258960 -0.259104
Max level 0.260178 0.257213 0.260178
Pk lev dB -11.69 -11.74 -11.69
RMS lev dB -24.04 -23.91 -24.17
RMS Pk dB -15.23 -15.23 -15.33
RMS Tr dB -1.#J -209.76 -1.#J
Crest factor - 4.06 4.20
Flat factor 0.00 0.00 0.00
Pk count 2 2 2
Bit-depth 31/32 31/32 31/32
Num samples 73.2M
Length s 381.504
Scale max 1.000000
Window s 0.050

so 12.04 - 11.69 = +0.35 dB

sox.exe %1 -n gain -12.04 upsample 4 fir Ebu_Fir_Coeff.txt stats

Overall Left Right
DC offset 0.000004 0.000003 0.000004
Min level -0.257842 -0.256317 -0.257842
Max level 0.255081 0.254555 0.255081
Pk lev dB -11.77 -11.82 -11.77
RMS lev dB -24.13 -24.00 -24.26
RMS Pk dB -15.32 -15.32 -15.42
RMS Tr dB -1.#J -1.#J -1.#J
Crest factor - 4.06 4.21
Flat factor 0.00 0.00 0.00
Pk count 2 2 2
Bit-depth 31/32 31/32 31/32
Num samples 67.3M
Length s 381.504
Scale max 1.000000
Window s 0.050
12.04 - 11.77 = +0.27 dB (note with upsample factor = 4 it will oversample to 176,4kHz not 192kHz)

ffmpeg ebur128 saids +0.3 dB
(ffmpeg stats saids 0.0 dB)

[LoRd_MuldeR]

R128Gain has been superseded by BS1770Gain which is more universal (but no GUI). The necessary ffmpeg and SoX libraries are stripped down to the absolute minimum (5 DLLs, but still 15 MB).

If we had a binary of BS1770Gain with all the required libs linked in statically, it would be much more useful (and probably a lot smaller).

But it seems they use runtime DLL loading and don't intend a fully static build. At least their Makefile fails with a missing DLL file, when configure was run with "--enable-static" plus "--disable-shared" option.

What is the reason to use FFmpeg anyway? Using FFmpeg to read a WAVE file is like taking a sledgehammer to crack a nut. SoX already supports a wide range of audio formats...


sox.exe %1 %1_out.wav gain -12.04 rate -v -s 192k gain -n -1 rate -v -s 44100
seems to work, normalizing at -1.0 -> -1.3 (maybe rate with -v -s is overkill)

What is this command supposed to do?

If I understand it correctly, all that this does is: First attenuate the audio by -12.04 dB, then upsample to 192 kHz, then apply plain old standard normalization filter (with target level of -1 dBFS) and finally downsample to 44.1 kHz again.


What is the difference to:
sox.exe %1 %1_out.wav gain -n -1

...except for a seemingly pointless up/downsampling roundtrip?

:confused:

[Motenai Yoda]

http://www.indexcom.com/tech/0dBFS+/

u will need ffmpeg to get the peak stats.

ps
sox.exe %1 %1_out.wav gain -12.04 rate -v -s 192k gain -n -1 rate -v -s 44100
≡
gain -12.04 rate -v -s 192k gain -n *NormalizationLevel* rate -v -s *OriginalSampleRate* (dither?)

with simple gain -n -1 sox will normalize taking into account only samples's max abs value
with oversampling it can taking into a more precise waveform representation

anyway it's only a small request, nothing vital

[LoRd_MuldeR]

http://www.indexcom.com/tech/0dBFS+/

u will need ffmpeg to get the peak stats.

I can't follow :rolleyes:

First you suggest using SoX. But when I ask you what your suggested SoX command-line is actually supposed to do – to my understanding it simply applies the plain old standard normalization filter, only combined with a seemingly pointless up-/downsamling rountrip (but maybe I'm missing something?) – you suddenly suggest using FFmpeg. Can you please elaborate on your previous suggestion, before you go on to the next one?

To make it clean again: What we need is a single SoX invocation (command-line) that performs all the required operations. Alternatively, some other CLI tool, which can do the required operations with a single invocation, could be integrated. But only if that tool is 100% stand-alone, i.e. it doesn't introduce any nasty dependencies. Clearly, BS1770Gain (R128GAIN), in its current form, isn't suitable for LameXP integration. Neither is FFmpeg.

[manolito]

What is the reason to use FFmpeg anyway? Using FFmpeg to read a WAVE file is like taking a sledgehammer to crack a nut. SoX already supports a wide range of audio formats...


As I understand it, FFmpeg is not just used to read a WAVE file (or decode other formats), instead it is mainly needed to perform the loudness detection pass as standardized by the ITU or EBU. This detection pass has to determine the "Integrated Loudness" of the source. The second pass done by SoX simply applies the necessary gain to reach the desired output level of -23 LUFS (EBU R128) or -18 LUFS (ReplayGain) or any other desired target loudness.


It looks like Motenai Yoda somehow tries to do the detection pass with SoX. Probably not possible IMO.

And additionally using standard normalization is totally destroying the original purpose of using EBU R128 or ReplayGain.


I have implemented EBU R128 normalization for AVStoDVD, and it works very well, especially as a postprocessor for DynamicAudioNormalizer. The main problem is that there is no clipping protection.

Of course the detection pass could additionally detect the max peak of the source, and the gain value for the second pass could be reduced so that no clipping occurs. But then you would not get uniform loudness over several sources.

The other way to avoid clipping would be to use a brickwall limiter before the second pass to reduce the peaks by the required amount. SoX has a command which applies limiting during the gain adjustment pass, but it is hard to find a setting which avoids clipping and at the same time does not destroy the dynamics.


All this is for AVStoDVD which deals with audio for films. With LameXP which will probably mostly deal with music there would be another design problem. If you convert to a format which supports loudness tagging (MP3, FLAC and others) you will want to just add the necessary tags instead of physically altering the loudness of the target file (which my AVStoDVD plugin does).


Cheers
manolito

[LoRd_MuldeR]

As I understand it, FFmpeg [...] is mainly needed to perform the loudness detection pass as standardized by the ITU or EBU.

I would have assumed that this is what happens inside the BS1770Gain program - or, more specifically, the lib1770 (http://sourceforge.net/projects/r128gain/files/lib1770/0.9/) library.

Ideally, we'd have just a minimalistic CLI front-end to lib1770. Maybe with libsndfile linked in, statically, for reading writing the WAVE files.


It looks like Motenai Yoda somehow tries to do the detection pass with SoX. Probably not possible IMO.

Probably. But even we used SoX only to apply the final gain adjustment (and do the detection pass in FFmpeg separately), we would use the SoX "gain" filter with a fixed delta, not in "normalization" mode.

(And we usually wouldn't need to apply a resampling for doing this)


And additionally using standard normalization is totally destroying the original purpose of using EBU R128 or ReplayGain.

That's what I was thinking too.


I have implemented EBU R128 normalization for AVStoDVD, and it works very well, especially as a postprocessor for DynamicAudioNormalizer. The main problem is that there is no clipping protection.

Of course the detection pass could additionally detect the max peak of the source, and the gain value for the second pass could be reduced so that no clipping occurs. But then you would not get uniform loudness over several sources.

That's always the problem when you want to apply a single constant gain value to the entire file: A single peak in the "loud" section will prevent applying adequate gain in "silent" sections - at least if you want to avoid clipping (or limiting/compression). So a more dynamic approach would be desired. But I think BS.1770 (EBU R128) is not really suitable for a "windowed" approach, as it computes so-called "integrated" loudness over the whole program (i.e. file or track).

[manolito]

I would have assumed that this is what happens inside the BS1770Gain program - or, more specifically, the lib1770 (http://sourceforge.net/projects/r128gain/files/lib1770/0.9/) library.

Ideally, we'd have just a minimalistic CLI front-end to lib1770. Maybe with libsndfile linked in, statically, for reading writing the WAVE files.

You are probably right about the lib1770 library.

About the minimalistic CLI frontend to lib1770 why don't you get in touch with Peter Belkner (he even speaks German... :) ) ?



Probably. But even we used SoX only to apply the final gain adjustment (and do the detection pass in FFmpeg separately), we would use the SoX "gain" filter with a fixed delta, not in "normalization" mode.

(And we usually wouldn't need to apply a resampling for doing this)

Absolutely. Resampling, high pass filtering and other stuff are required for the detection pass, not for the gain adjustment.


That's always the problem when you want to apply a single constant gain value to the entire file: A single peak in the "loud" section will prevent applying adequate gain in "silent" sections - at least if you want to avoid clipping (or limiting/compression). So a more dynamic approach would be desired. But I think BS.1770 (EBU R128) is not really suitable for a "windowed" approach, as it computes so-called "integrated" loudness over the whole program (i.e. file or track).

Absolutely correct (at least if your result has to comply to the EBU R128 standard). No way to avoid a 2-pass process.

AFAIK the FooBar devs implemented a different design for ReplayGain. Their detection pass is much shorter, maybe it even is a "windowed" approach. I am not familiar with FooBar, though...



Cheers
manolito

[Motenai Yoda]

TruePeak/bs.1770 only concern about max peak of the waveform, not the short/medium term or integrate loudness, those are for r128.

also in that cli (first one) normalize on a oversampled waveform, so finds the delta and then normalize according to it (so internally 2 pass), finally downscale-back to 48kHz.
It doesn't calculate the delta and normalize at delta level.

It can also be done finding the TP level, and using sox or anything (even ffmpeg) to apply gain "delta" factor on an un-resampled waveform.

As #1232 this delta can be roughly found even with sox.

ffmpeg reading is somewhat different coz it uses hardcoded pre/post filters that, unlikely deprecated revisions, are no more mentioned in lastest bs.1770 (but lowpass).

anyway ffmpeg oversample at 192k too and it comply to the EBU R128 standard only for 48kHz content.

[LoRd_MuldeR]

LameXP v4.12 Alpha-7

Changes between v4.11 and v4.12 [unreleased]:
* Added Hungarian translation, contributed by Zityi's Translator Team zityisoft@gmail.com
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated MediaInfo to v0.7.74 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore

[LoRd_MuldeR]

LameXP v4.12 Alpha-8

Changes between v4.11 and v4.12 [unreleased]:
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added Hungarian translation, contributed by Zityi's Translator Team zityisoft@gmail.com
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated MediaInfo to v0.7.74 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore

[Randy31416]

On my system (Win 7 64-bit) the output filenames do not retain the same name as the input filenames even though I have left the rename-output-files option unchecked. In particular, my input filenames often have more than one space character in a row to improve formatting when large aggregates of files are listed by other software, and LameXp renames them by squeezing all such cases down to a single space only. Is there any way to get the program to preserve the filename? Other than that (and it is a nit), what a great program, and thanks. The parallel processing of encoding (4-way for me) is a boon.

[SeeMoreDigital]

On my system (Win 7 64-bit) the output filenames do not retain the same name as the input filenames even though I have left the rename-output-files option unchecked.

Hi and welcome to the forum,

Can you give us some before and after examples?


Cheers

[LoRd_MuldeR]

File name strings generally are simplified() (http://doc.qt.io/qt-4.8/qstring.html#simplified), in order to removed typographical "mistakes", such as multiple space characters in a row.

[Randy31416]

File name strings generally are simplified() (http://doc.qt.io/qt-4.8/qstring.html#simplified), in order to removed typographical "mistakes", such as multiple space characters in a row.
So there is no way within LameXP to leave the filenames intact? (I do note, and thank you for, the quotes around "mistakes", as I infer that you recognize that in my case the extra spaces are not mistakes. The whole overly-precise formatting of titles, on the other hand . . . .)

I'd prefer it if the names were untouched. However, as a workaround, I wrote AutoHotkey scripts that I call before and after compression. The before script turns all blanks into @s (a character that never appears in my titles); the after script turns all @s into blanks. The result has the form I want, but I just have to remember to invoke the scripts.

[LoRd_MuldeR]

So there is no way within LameXP to leave the filenames intact? (I do note, and thank you for, the quotes around "mistakes", as I infer that you recognize that in my case the extra spaces are not mistakes. The whole overly-precise formatting of titles, on the other hand . . . .)

I'd prefer it if the names were untouched. However, as a workaround, I wrote AutoHotkey scripts that I call before and after compression. The before script turns all blanks into @s (a character that never appears in my titles); the after script turns all @s into blanks. The result has the form I want, but I just have to remember to invoke the scripts.

Okay, I have relaxed the clean_file_name() (https://github.com/lordmulder/MUtilities/blob/master/include/MUtils/Global.h#L98) function a bit, so that it uses trimmed() instead of simplified(), retaining spaces in the middle of a file name.

You can try this test build:
https://www.sendspace.com/file/fnjqaj

[LoRd_MuldeR]

LameXP v4.12 Beta-1

Changes between v4.11 and v4.12 [unreleased]:
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated MediaInfo to v0.7.74 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.22.2 (2015-05-24), compiled with GCC 5.1.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore

[lethedoom]

SourceForge website mystery.

http://sourceforge.net/projects/lamexp/files/Snapshots%20(BETA)/

Today I find recent history wiped out:

Looking for the latest version? Download LameXP.2014-06-23.Release-Static.Build-1558.exe
Home / Snapshots (BETA)
Name Modified Size Downloads / Week Status
Parent folder
Totals: 182 Items
2015-03-28 2015-03-28

Back to the present today 7.18.2015.

[LoRd_MuldeR]

SourceForge file release system can be a bit funky at times...

See also:
http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration/

[SeeMoreDigital]

This is a new one: -

http://i59.tinypic.com/t6t79e.png

Is it anything I may have done?

Currently running Windows 10 Pro (64-bit) Build: 10240

[LoRd_MuldeR]

You mean those warnings about "failed to open registry key"?

I recently moved some more registry-related stuff to the MUtilities library, in order to eliminate more redundant code in LameXP/MediaInfoXP. Quite possible that the new code is more pedantic, while the old code just failed silently.

Anyway, I assume those warnings originate from the Shell Integration code. Probably nothing to worry about. But I will need to look into this in detail...

[LoRd_MuldeR]

LameXP v4.12 Beta-2

Changes between v4.11 and v4.12 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-5
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated MediaInfo to v0.7.74 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.22.2 (2015-05-24), compiled with GCC 5.1.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore

[LoRd_MuldeR]

This is a new one: -

http://i59.tinypic.com/t6t79e.png

Is it anything I may have done?

Currently running Windows 10 Pro (64-bit) Build: 10240

Okay, after some investigation, I identified two issues that may cause these warnings:

The ShellExtension code checks whether there already is an existing file type for each file extension that is "supported" by LameXP. It does so by trying to open the corresponding registry key, i.e. HKEY_CLASSES_ROOT\.foo. If the key does not exist, the key cannot be opened and thus the warning pops up. Not really a problem, but I now added an additional check to see whether the key exists or not, before we actually try to open it. This makes the warning go away.
If there is no existing file type for a "supported" file extension yet, we cannot add the LameXP entry to the existing file type, obviously. So, in this case, we need to register the "missing" file extension to our own type. Unfortunately, there was a regression in revision 027f4d5 that caused this task to fail. More specifically, the key was created under HKEY_CURRENT_USER\.foo, rather than HKEY_CURRENT_USER\Software\Classes\.foo. This problem has been fixed now.


Please try with this Test build, which should resolve all issues listed above:
https://www.sendspace.com/file/rn18m7

BTW: If you find any "misplaced" registry entries (created by the effected versions of LameXP), which would be in the form of HKEY_CURRENT_USER\.foo, you should simply delete them manually!

[SeeMoreDigital]

Nice one... It appears "all is good": -

http://i58.tinypic.com/29malgz.png

:D

[LoRd_MuldeR]

Here is a Test build created with VS2015:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-08-11/

(Only "shared" build for now, because I haven't gotten around to build "static" Qt with VS2015 yet. Pre-Win10 users may need to install the Redist package)

[LoRd_MuldeR]

LameXP v4.12 Beta-3

Changes between v4.11 and v4.12 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-5
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added Hungarian translation, contributed by Zityi's Translator Team zityisoft@gmail.com
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated Vorbis encoder to OggEnc v2.87 (2015-08-03), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.74 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.22.4 (2015-08-12), compiled with GCC 5.1.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore
* Some installer improvements have been implemented (especially in "update" mode)
* Full support for Windows 10 RTM (Build #10240)

[LoRd_MuldeR]

LameXP v4.12 Beta-4

Changes between v4.11 and v4.12 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-5
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added Hungarian translation, contributed by Zityi's Translator Team zityisoft@gmail.com
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated Vorbis encoder to OggEnc v2.87 (2015-08-03), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.74 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.22.4 (2015-08-12), compiled with GCC 5.1.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore
* Enable the embedding of cover artwork for Opus encoder (opusenc), using the --picture option
* Some installer improvements have been implemented (especially in "update" mode)
* Full support for Windows 10 RTM (Build #10240)

[SeeMoreDigital]

Thanks,

The new version is booting-up fine using Win10 (build 10525) ;)

[LoRd_MuldeR]

LameXP v4.12 Beta-6
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-08-29/

Changes between v4.11 and v4.12 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-5
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated Vorbis encoder to OggEnc v2.87 (2015-08-03), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.76 (2015-08-06), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.22.4 (2015-08-12), compiled with GCC 5.1.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated Monkey's Audio binary to v4.16 (2015-03-24), compiled with ICL 15.0 and MSVC 12.0
* Updated WavPack decoder to v4.75.0 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore
* Enable the embedding of cover artwork for Opus encoder (opusenc), using the --picture option
* Some installer improvements have been implemented (especially in "update" mode)
* Full support for Windows 10 RTM (Build #10240)

[LoRd_MuldeR]

I'd rather have the application self-contained in a folder, where I put it. If I install it in D:\Programs\Lame , I don't expect it to write tens of megs to c:\ [...] \ TEMP folder. I'd rather have a Lame\Tools or Lame\Temp folder created automatically and so on. Or let user choose.
Maybe I run my Windows from a 64 GB SSD and I only have 300-500 MB free on the SSD. I wouldn't like to kill write cycles in those 300-500 MB of free space with 20-30 MB of tools. I know, it's unlikely, but you never know.

Also consider that you may want to make a "portable" version of the application, in which case having the files extracted in a subfolder would make it easy for you to just set some flags inside your application to just check for existence of those files at start instead of trying to unpack them from the executable each time.

Try this one:
https://www.sendspace.com/file/it57wv

[pepar]

Hi,

I just started using this to batch convert an APE'd CD library to LAME. Windows Explorer with the APE files shows the file name, track #, title, artist and album. Opening those files in LameXP, everything is missing except the file name. After encoding, that has not changed. I have set the Rename Output Files to [<TrackNo>] <Artist> - <Album> - <Title>. Still, none of that data is picked up from the APE files.

Any ideas?

Thanks,
Jeff

[LoRd_MuldeR]

Hi,

I just started using this to batch convert an APE'd CD library to LAME. Windows Explorer with the APE files shows the file name, track #, title, artist and album. Opening those files in LameXP, everything is missing except the file name. After encoding, that has not changed. I have set the Rename Output Files to [<TrackNo>] <Artist> - <Album> - <Title>. Still, none of that data is picked up from the APE files.

Any ideas?

Thanks,
Jeff

If you just drop the .APE file into LameXP and go to the "Show Details", does it show the meta info?

If not, what if you open the "problematic" file with MediaInfo? Does it detect the info :confused:

[pepar]

If you just drop the .APE file into LameXP and go to the "Show Details", does it show the meta info?
It does not. And the problematic file is the entire CD library.

If not, what if you open the "problematic" file with MediaInfo? Does it detect the info :confused:
Well, maybe that is my problem. Does MediaInfo install with LameXP? Do I need to have it "independently" of LameXP? ... I didn't notice where I would point LameXP to it ...

Jeff

[pepar]

Just installed MediaInfo and then reopended LameXP. Still no tagging. Will restart PC and see if that fixes it.

edit: Resrtarted PC. No joy. Loaded a file into MediaInfo and can't find where I would see the meta tags. However, I loaded a file into MP3Tag and the info displayed immediately.

edit: OK, found "sheet" anc customized it for Artist, Album, Track # and Title. No joy. None of that is displayed. Yet Mp3tag shows it.

[LoRd_MuldeR]

Well, maybe that is my problem. Does MediaInfo install with LameXP? Do I need to have it "independently" of LameXP?

LameXP uses MediaInfo to detect the type of a file. It also uses MediaInfo to extract the meta info from the input file.

But you do not need to install MediaInfo separately. It's already included with LameXP! Still, it would be interesting to know if standalone MediaInfo correctly detects the meta info from your "problematic" file or not.

If it doesn't, then this clearly is a MediaInfo bug/limitation and there is nothing that could be done on the LameXP side. Otherwise, it would indicate some LameXP bug...

[pepar]

LameXP uses MediaInfo to detect the type of a file. It also uses MediaInfo to extract the meta info from the input file.

But you do not need to install MediaInfo separately. It's already included with LameXP! Still, it would be interesting to know if standalone MediaInfo correctly detects the meta info from your "problematic" file or not.

If it doesn't, then this clearly is a MediaInfo bug/limitation and there is nothing that could be done on the LameXP side. Otherwise, it would indicate some LameXP bug...
See above edits. Looks like a MediaInfo bug ...

[LoRd_MuldeR]

See above edits. Looks like a MediaInfo bug ...

In this case, please send bug report (or feature request) to the MediaInfo developer.

[pepar]

LameXP uses MediaInfo to detect the type of a file. It also uses MediaInfo to extract the meta info from the input file.

But you do not need to install MediaInfo separately. It's already included with LameXP! Still, it would be interesting to know if standalone MediaInfo correctly detects the meta info from your "problematic" file or not.

If it doesn't, then this clearly is a MediaInfo bug/limitation and there is nothing that could be done on the LameXP side. Otherwise, it would indicate some LameXP bug...

Just looking at the MediaInfo page, I don't see where it does anything at all with audio track tagging. It is for file information in the context of movie audio, e.g. codec, bitrate, sample depth, etc. Beyond that, it says APE is a supported format, but it gives no details about what tags are supported. If APE falls under Other, than it only supports the stuff I mentioned above.

Anywho, I think I see my problem.

[pepar]

In this case, please send bug report (or feature request) to the MediaInfo developer.

Thanks, I will pursue it from that angle.

Jeff

[Gravitator]

Привет! Through video card has not been any projects for encoding MP3?

[pepar]

Thanks, I will pursue it from that angle.

Jeff

Following up to my issue - my workaround was to use a piece of software that didn't have a reliance on MediaInfo. It was not multi-threaded or multicore-aware and ran at 20% of the speed of LameXP. (And I installed it immediately as it was the naggiest freeware I have ever encountered.) But it did carry the tags through the conversion.

I am someone who *always* contributes to authors of freeware and wish I had been able to use LameXP.

I am not a troll nor am I trying to flame this fine work; just being honest in the hope that this limitation is fixed. I can't be the only user wanting to convert tagged audio files.

Jeff

[LoRd_MuldeR]

Привет! Through video card has not been any projects for encoding MP3?

:confused:


Following up to my issue - my workaround was to use a piece of software that didn't have a reliance on MediaInfo. It was not multi-threaded or multicore-aware and ran at 20% of the speed of LameXP. (And I installed it immediately as it was the naggiest freeware I have ever encountered.) But it did carry the tags through the conversion.

If we didn't use MediaInfo to detect the file type and the meta info, we would have to manually implement detection code for several dozens of file formats - which is condemned to failure. So, even if MediaInfo does not support a particular file format (by now), the benefit of using MediaInfo still outweighs this little shortcoming by far. I'm not aware of any library or tool that detects as many file formats as MediaInfo does, let alone the extraction of meta tags.

[LoRd_MuldeR]

LameXP v4.12 RC-1
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-09-28/

Changes between v4.11 and v4.12 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-5
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated Vorbis encoder to OggEnc v2.87 (2015-08-03), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.76 (2015-08-06), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.22.4 (2015-08-12), compiled with GCC 5.1.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated Monkey's Audio binary to v4.16 (2015-03-24), compiled with ICL 15.0 and MSVC 12.0
* Updated WavPack decoder to v4.75.0 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore
* Enable the embedding of cover artwork for Opus encoder (opusenc), using the --picture option
* Some installer improvements have been implemented (especially in "update" mode)
* Full support for Windows 10 RTM (Build #10240)

[pepar]

If we didn't use MediaInfo to detect the file type and the meta info, we would have to manually implement detection code for several dozens of file formats - which is condemned to failure. So, even if MediaInfo does not support a particular file format (by now), the benefit of using MediaInfo still outweighs this little shortcoming by far. I'm not aware of any library or tool that detects as many file formats as MediaInfo does, let alone the extraction of meta tags.
I completely agree, even though the little shortcoming was a show-stopper for me, I really liked your software.

I just looked to see how I could donate ... put my money where my ... yadda, yadda. While I could help you order food and drink in a Mexican restaurant, I can't offer translation. Or code.

So, all I can do is thank you.

Jeff

[lethedoom]

I have ignored the 4.12 betas until this RC 1 iteration. I had to struggle with Avast anti virus to download and install it and have notified them that they are getting a false positive result deeming it suspicious and forbidding its download. They will review it the next cycle of their process. In the past they have always conceded Lame XP is safe when challenged. I found the RC 1 loads quickly and performs well. Thanks again for this gift.

[Atak_Snajpera]

@LoRd_MuldeR
It would be cool if we could search and download cover art directly from LameXP. I've done similar app but for movie posters.
http://i.imgur.com/uY8JbUW.png

You could use http://musicdatabase.co/ as source.

[Atak_Snajpera]

@LoRd_MuldeR
Here is binary and source in Delphi. You can do with this code whatever you want.

Required components:
Embedded Web Browser -> https://sourceforge.net/projects/embeddedwb/
JEDI Visual Component Library -> http://jvcl.delphi-jedi.org/

DOWNLOAD -> http://www.mediafire.com/download/hhok6pckhlodmay/DownloadCover.7z

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

[SeeMoreDigital]

Oh jeez...

Seeing 'The Hoff' at any time of the day can be a bit of a shock :scared:

[shmizan]

when I put several flacs from different folders, for example 4 CDs with ~18 tracks in each, it sums up to ~70 tracks, and when choosing to name by track number, it names the first track of CD 2 as 19 - artist - title, instead of 01 - artist - title.
is there a possibility to change this behavior so it would name it according to the meta data track number?

[LoRd_MuldeR]

when I put several flacs from different folders, for example 4 CDs with ~18 tracks in each, it sums up to ~70 tracks, and when choosing to name by track number, it names the first track of CD 2 as 19 - artist - title, instead of 01 - artist - title.
is there a possibility to change this behavior so it would name it according to the meta data track number?

If you set "Position" to "Generate from list position" it does exactly what you describe: The file's "track number" will be set to the file's position on the list.

Set it to "Unspecified (copy from source)", if you wish to retain the "track number" stored in the original file - only works, if such info was present in the original file, of course!


@LoRd_MuldeR
It would be cool if we could search and download cover art directly from LameXP. I've done similar app but for movie posters.
http://i.imgur.com/uY8JbUW.png

You could use http://musicdatabase.co/ as source.

This doesn't exactly make me confident about the legality of that "service":
http://musicdatabase.co/page/about


Oh jeez...

Seeing 'The Hoff' at any time of the day can be a bit of a shock :scared:

I have to admit, I loved watching Knight Rider, back in the 1980's. That and The A-Team (the original series I mean), of course :D

[Atak_Snajpera]

This doesn't exactly make me confident about the legality of that "service":
http://musicdatabase.co/page/about
Haha! Indeed very silly placeholder text :) But is this a real problem here? We only download 300x300 cover art not whole mp3 file ;) For example mp3tag application uses Amazon.com as cover art source but in my opinion http://musicdatabase.co has higher quality images than amazon. Example
http://img2-ak.lst.fm/i/u/300x300/84dd22572ed6b29c155c4fbf956419c0.png
http://musicdatabase.co/artist/Adam_F/album/Colours

https://images-na.ssl-images-amazon.com/images/I/51KFAc0BYLL._SS280.jpg
http://www.amazon.com/gp/product/B0011XBOJ6?keywords=adam%20f&qid=1444486519&ref_=sr_1_1&sr=8-1

[jpsdr]

Isn't "The Hoff" picture from the excellent Kung Fury ?

[LoRd_MuldeR]

Isn't "The Hoff" picture from the excellent Kung Fury ?

Yup ;)


Haha! Indeed very silly placeholder text :) But is this a real problem here? We only download 300x300 cover art not whole mp3 file ;)

Well, unless they have official permission from the film and/or music studios to redistribute the cover artwork - and it doesn't exactly look to me like they have ;) - they are moving on shaky ground. Remember how the once popular CDCovers.cc got shut down? Now, you could say that this is all their problem. But downloading stuff from an illegitimate source can lead to legal implications for the end-user as well. That's something I really don't want get involved with.

Furthermore, even if we leave the legal issues aside for now, what if they stop their service tomorrow for whatever reason? Sure, any "online" service may shut down tomorrow. But the chance that a big and well-recognized service stops their business all of a sudden is much lower. At the same time, making your software depend on some rather "dubious" service, like this one, is not what we want.

Last but not least, after a quick look at your code, it seems you are not even using an official API to fetch the covers. Instead, it looks to me like you are parsing their HTML code. So, even if we assume that this is a legitimate service, using the service in that way might easily be a violation of their ToS (Terms of Service). And, of course, you will have to constantly adapt your code to any change they make to their site. Again something we certainly don't want.

[LoRd_MuldeR]

LameXP v4.12 RC-2

Changes between v4.11 and v4.12 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-5
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated Vorbis encoder to OggEnc v2.87 (2015-08-03), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.76 (2015-08-06), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.22.4 (2015-08-12), compiled with GCC 5.1.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated Monkey's Audio binary to v4.16 (2015-03-24), compiled with ICL 15.0 and MSVC 12.0
* Updated WavPack decoder to v4.75.0 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore
* Enable the embedding of cover artwork for Opus encoder (opusenc), using the --picture option
* Some installer improvements have been implemented (especially in "update" mode)
* Full support for Windows 10 RTM (Build #10240)

[Atak_Snajpera]

So how about this then https://musicbrainz.org/

[LoRd_MuldeR]

So how about this then https://musicbrainz.org/

This looks like something we could actually use. Looks pretty serious to me (in existence since ~2000). And they have a proper REST-based API and even offer client-libraries in C/C++. Maybe I will have a look, when I have time :)

[lethedoom]

LameXP v4.12 RC-2
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2015-10-10/

Avast scans the RC2 exe and finds no problems. Windows 10 Home cautions but allows election to install.

[shmizan]

If you set "Position" to "Generate from list position" it does exactly what you describe: The file's "track number" will be set to the file's position on the list.

Set it to "Unspecified (copy from source)", if you wish to retain the "track number" stored in the original file - only works, if such info was present in the original file, of course!

Hi, I figured it out eventually, but thanks for the answer.
not used to being the one that can't find the settings, probably comes with age :rolleyes:
:thanks:

[LoRd_MuldeR]

LameXP v4.12 RC-3

Changes between v4.11 and v4.12 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-5
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated Vorbis encoder to OggEnc v2.87 (2015-08-03), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.76 (2015-08-06), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.22.4 (2015-08-12), compiled with GCC 5.1.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated Monkey's Audio binary to v4.16 (2015-03-24), compiled with ICL 15.0 and MSVC 12.0
* Updated WavPack decoder to v4.75.0 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore
* Enable the embedding of cover artwork for Opus encoder (opusenc), using the --picture option
* Some installer improvements have been implemented (especially in "update" mode)
* Full support for Windows 10 RTM (Build #10240)

[Sp00kyFox]

hi Lord_Mulder,

I'm using the latest stable build v4.11 Final-1 build 1700. I'd like to request a feature for the usage with qaac. right now you can't use the --cvbr option of qaac which is actually the ABR method of this encoder (while --abr is basically a constant bitrate with small leeway). I tried to use the manual commandline option but since lamexp already uses --tvbr, --abr or --cbr I can't add --cvbr on top of it, the encoding process then quits with an error ("Encoding mode options are exclusive.")
Is there a solution for that problem or could you add another option (or replace --abr with --cvbr for qaac)?

and another thing.. do you plan to add lossyflac to the encoder selection? I would love to see that addition.

ps: thanks for the tool and the work you put into it. it's really useful and convenient :thanks:

[LoRd_MuldeR]

Adding yet another (ABR) bitrate mode seems difficult, as QAAC would really be the only encoder to which this mode applies. I see two options:

1. Generally make "ABR" synonymous for "--cvbr" instead of "--abr", when it comes to QAAC.
2. Add an option to the advanced options dialog, which makes QAAC use "--cvbr" instead of "--abr" in "ABR" mode.

I need to think about it, but if "--cvbr" is considered the "actual ABR method", is there any reason to prefer "--abr" over "--cvbr" ???

[Sp00kyFox]

I need to think about it, but if "--cvbr" is considered the "actual ABR method", is there any reason to prefer "--abr" over "--cvbr" ???
I don't really know, I guess not. I could only imagine that it is useful for some really restrictive standalone player. but in that case one could use the actual constant bitrate method --cbr instead of --abr, there is not much of a difference between those two.

[LoRd_MuldeR]

LameXP v4.12 RC-4

Changes between v4.11 and v4.12 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-5
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated Vorbis encoder to OggEnc v2.87 (2015-08-03), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.76 (2015-08-06), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.22.4 (2015-08-12), compiled with GCC 5.1.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated Monkey's Audio binary to v4.16 (2015-03-24), compiled with ICL 15.0 and MSVC 12.0
* Updated WavPack decoder to v4.75.0 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore
* Fixed parsing of command-line parameters, regression in MUtilities library (LameXP v4.12 RC-1)
* QAAC encoder is now using --cvbr instead of --abr when "ABR" mode is selected
* Enable the embedding of cover artwork for Opus encoder (opusenc), using the --picture option
* Some installer improvements have been implemented (especially in "update" mode)
* Full support for Windows 10 RTM (Build #10240)

[Sp00kyFox]

works fine, thx for the quick update. I did a little search on that matter and found some official apple documentation about the different encoding modes:
https://developer.apple.com/library/mac/technotes/tn2237/_index.html#//apple_ref/doc/uid/DTS40008147-CH1-SUBSECTION11

this gives the following order for the bitrate variation (high to low):
--tvbr, --cvbr, --abr, --cbr

according to this document cvbr uses the bitrate setting as a lower limit. so I'm not sure which one should be the correct choice, maybe I misled you. in terms of hitting the target rate --abr is the appropriate choice. --cvbr allows more variance but definitely results in a higher bitrate on average than the user selection. it's your decision in the end but I think regarding the user expection for the setting "average bitrate" the option --abr should be prefered (or you add a switch to the advanced settings like you suggested).

sorry for the confusion but hopefully I shed some light on qaac's encoding options.

[Chetwood]

So, I tested LameXP the other day, uninstalled it but the context menu entries in explorer remained. What gives?

[LoRd_MuldeR]

So, I tested LameXP the other day, uninstalled it but the context menu entries in explorer remained. What gives?

Actually the logic to create or to remove the Shell Integration is in the LameXP main program, not in the (Un)Installer, which allows the user to enable/disable the Shell Integration at any time from the LameXP options.

This code is surprisingly complex, because the way how Windows manages file associations is surprisingly complex — file extensions are registered to file types and shell operations are registered to file types, so we need to figure out all file types to which at least one "supported" file extension is registered and then we must register our operation to each of these types (removing the Shell Integration requires the inverse process) — so I have no plans to replicate this code in the Uninstaller.

Instead I have now added a new "--uninstall" switch to the LameXP main program, which will be called by the Uninstaller, in order to remove the Shell Integration. Please try again with this test build:
http://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-RC4.2015-10-20.Release-Static.Build-1815.exe/download

[Chetwood]

Thanks, but I've already removed them manually and it looks like I'm gonna stick with Foobar cause it also converts FLAC.

[LoRd_MuldeR]

LameXP v4.12 has been released!
https://github.com/lordmulder/LameXP/releases/latest

Changes between v4.11 and v4.12 [2015-10-23]:
* Upgraded build environment to Microsoft Visual Studio 2013 with Update-5
* Updated Qt runtime libraries to v4.8.7 Final (2015-05-25), compiled with MSVC 12.0
* Added support for building LameXP and MUtilities with Visual Studio 2015
* Added Hungarian translation, contributed by Zityi's Translator Team <zityisoft@gmail.com>
* Added optional support for the libfdk-aac encoder, using the fdkaac front-end by nu774
* Added detection of the 64-Bit version of QAAC encoder, requires 64-Bit Apple Application Support
* Added enhanced file renaming option: Default file extensions can now be overwritten
* Added enhanced file renaming option: Files can now be renamed via the regular expression engine
* Added capability to select multiple files on "Source Files" tab
* Updated Vorbis encoder to OggEnc v2.87 (2015-08-03), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.76 (2015-08-06), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.22.4 (2015-08-12), compiled with GCC 5.1.0
* Updated ALAC decoder to refalac v1.47 (2015-02-15), based on reference implementation by Apple
* Updated Monkey's Audio binary to v4.16 (2015-03-24), compiled with ICL 15.0 and MSVC 12.0
* Updated WavPack decoder to v4.75.0 (2015-05-25), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.19 (2015-02-27), compiled with GCC 4.9.2
* Fixed potential deadlock in Cue Sheet import dialog when "Browse..." button is clicked
* Fixed function to restore the default Temp folder, if custom Temp folder doesn't exist anymore
* Fixed parsing of command-line parameters, regression in MUtilities library (LameXP v4.12 RC-1)
* QAAC encoder is now using --cvbr instead of --abr when "ABR" mode is selected
* Enable the embedding of cover artwork for Opus encoder (opusenc), using the --picture option
* Some installer improvements have been implemented (especially in "update" mode)
* Full support for Windows 10 RTM (Build #10240)
* Updated language files (big thank-you to all contributors !!!)

[manolito]

Thanks, but I've already removed them manually and it looks like I'm gonna stick with Foobar cause it also converts FLAC.

Sorry, am I missing something? LameXP has FLAC support since quite some time... :confused:


Cheers
manolito

[manolito]

Thanks LoRd_MuldeR for the new stable version... :thanks:

Works well on my ancient computer, even feels a little faster than the previous version.

One small cosmetic bug I found:
When converting to the APE format and having MetaData unchecked, LameXP still runs its tagger app after the conversion and finishes with an error (at least one tag must be specified). The converted file is perfect, though.


Cheers
manolito

[Sparktank]

Quite a few updates. Thanks a lot. Been waiting for the next Stable. :)

[LoRd_MuldeR]

Sorry, am I missing something? LameXP has FLAC support since quite some time... :confused:
I guess he meant that Foobar can do it too (just like LameXP), so he rather stays with Foobar ;)

When converting to the APE format and having MetaData unchecked, LameXP still runs its tagger app after the conversion and finishes with an error (at least one tag must be specified). The converted file is perfect, though.
And your are telling me this now? As if we didn't have like a dozen Beta versions and four RC's :p

BTW: It looks like the Nero AAC encoder actually has a similar issue, but the neroAacTag tool is more forgiving...

Try this TEST version:
http://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-TEST.2015-10-24.Release-Static.Build-1820.exe/download

[LoRd_MuldeR]

works fine, thx for the quick update. I did a little search on that matter and found some official apple documentation about the different encoding modes:
https://developer.apple.com/library/mac/technotes/tn2237/_index.html#//apple_ref/doc/uid/DTS40008147-CH1-SUBSECTION11

this gives the following order for the bitrate variation (high to low):
--tvbr, --cvbr, --abr, --cbr

according to this document cvbr uses the bitrate setting as a lower limit. so I'm not sure which one should be the correct choice, maybe I misled you. in terms of hitting the target rate --abr is the appropriate choice. --cvbr allows more variance but definitely results in a higher bitrate on average than the user selection. it's your decision in the end but I think regarding the user expection for the setting "average bitrate" the option --abr should be prefered (or you add a switch to the advanced settings like you suggested).

sorry for the confusion but hopefully I shed some light on qaac's encoding options.

I'm probably going to make this an option in one of the future versions.

[manolito]

And your are telling me this now? As if we didn't have like a dozen Beta versions and four RC's :p

Yes, the test version fixes it... :cool:

And for the Beta and RC versions:
I have become a little lazy testing these versions, and one reason is that you are making it a little too hard.

The debug console is annoying (yes, I know the command line option to make it disappear), and all test versions expire after 30 days. But the main reason for my reluctance to test them is that they screw up the settings for the stable version, it is way too much hassle to get back to the stable version with all previous settings intact.


Cheers
manolito

[LoRd_MuldeR]

But the main reason for my reluctance to test them is that they screw up the settings for the stable version, it is way too much hassle to get back to the stable version with all previous settings intact.
Actually the settings for each version are stored separately/independently, so switching between different versions shouldn't be an issue.

[ak1]

I tried to upgrade to v4.12 build #1818. During installation my Windows 10 Pro 64 Bit machine is crashing and rebooting. I also tried a reinstall after previous version v4.11 has been removed. Same effect.

The crash error is "system_service_exception".

From the eventlog:
"Der Computer wurde nach einem schwerwiegenden Fehler neu gestartet. Der Fehlercode war: 0x0000003b (0x00000000c0000005, 0xfffff8032131983f, 0xffffd0002562ee60, 0x0000000000000000). Ein volles Abbild wurde gespeichert in: C:\WINDOWS\MEMORY.DMP. Berichts-ID: 102715-8625-01."

Anyone with hints to address this?

Thanks,
ak1

[LoRd_MuldeR]

ak1, see my response here:
https://github.com/lordmulder/LameXP/issues/27

I have no idea. Actually, user-space programs, like LameXP or the LameXP setup program, can not cause BSoD (Blue Screen of Death) – neither accidentally nor willingly – because they do not have kernel-mode privileges. Would be pretty dreadful, if a single program could crash the whole system.

Thus, if you encounter BSoD, this is either because of a bug in the operating system itself, or, more likely, the fault of a buggy device driver. Well, it could also be a hardware issue, e.g. corrupted memory module. Anyway, if the BSoD occurred while installing LameXP, then this was just a coincidence – a symptom of some other problem. LameXP or the LameXP installer are not the actual cause of the problem.

Having said that: Is the problem reproducible, i.e. does it happen every time that you try to install LameXP r1818? And does it happen never when you install LameXP r1700? This would be pretty weird, because the installer doesn't do anything special, really. It's just a pretty boring NSIS installer. And the changes to the installer between r1700 and r1818 are minuscule – and certainly nothing that could cause a BSoD.

See also:
https://www.google.de/search?q=0x0000003b

[ak1]

Thank you for the quick response.
You are the expert, and after your statements I think this is already clear to you. Nevertheless, the short interpretation of my crashdump:


On Tue 27.10.2015 07:39:47 GMT your computer crashed
crash dump file: C:\WINDOWS\Minidump\102715-8625-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x14E2E0)
Bugcheck code: 0x3B (0xC0000005, 0xFFFFF8032131983F, 0xFFFFD0002562EE60, 0x0)
Error: SYSTEM_SERVICE_EXCEPTION
file path: C:\WINDOWS\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that an exception happened while executing a routine that transitions from non-privileged code to privileged code.
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.


I was just able to reproduce this right away. The last thing I was seeing in the setup before the crash was something like "Anwendungen suchen ... bitte warten" and a percentage counter.

Prior to that I installed v4.11 (build #1700) without any issues and removed it (keeping config) prior doing the v4.12 test.

Regards,
ak1

[LoRd_MuldeR]

So, this is pretty much in accordance with what I said before:
Bug check description: This indicates that an exception happened while executing a routine that transitions from non-privileged code to privileged code.
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.


TI was just able to reproduce this right away. The last thing I was seeing in the setup before the crash was something like "Anwendungen suchen ... bitte warten" and a percentage counter.

Well, that is the "locked list" plug-in, which is scanning for running applications that might be locking one of our files and thus would prevent the installation from succeeding.

This is a "standard" plug-in, widely used in many installers out there. Also, I have been using this plug-in for a very long time. Probably ever since the first LameXP v4.xx release. I highly doubt that this has anything to do with it.

Furthermore, the installer runs trough just fine on both, my Windows 10 (x64) notebook that is currently running Windows 10 RTM as well as my Windows 10 (x64) VM that is running the latest "insider" build.

[ak1]

OK, just let me know if I can help by testing/checking something for you.

Cheers,
ak1

[Gravitator]

Where to press stereo to mono transform coding for FLAC or WAVE ?

[LoRd_MuldeR]

LameXP v4.13 RC-1

Changes between v4.12 and v4.13 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015
* Apply the original file's "creation" and "last modified" date/time to the output file (optional)
* Updated Vorbis encoder to OggEnc v2.88 (2015-09-10), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.78 (2015-10-02), compiled with ICL 15.0 and MSVC 12.0
* Fixed resampling bug with Vorbis encoder, regression in OggEnc v2.87
* Fixed creation of Monkey's Audio (APE) files, when no meta data is being embedded

[LoRd_MuldeR]

LameXP v4.13 RC-2

Changes between v4.12 and v4.13 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015
* Apply the original file's "creation" and "last modified" date/time to the output file (optional)
* Updated Vorbis encoder to OggEnc v2.88 (2015-09-10), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.78 (2015-10-02), compiled with ICL 15.0 and MSVC 12.0
* Fixed resampling bug with Vorbis encoder, regression in OggEnc v2.87
* Fixed creation of Monkey's Audio (APE) files, when no meta data is being embedded

[LoRd_MuldeR]

LameXP v4.13 RC-3

Changes between v4.12 and v4.13 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015
* Apply the original file's "creation" and "last modified" date/time to the output file (optional)
* Updated Vorbis encoder to OggEnc v2.88 (2015-09-10), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.78 (2015-10-02), compiled with ICL 15.0 and MSVC 12.0
* Fixed resampling bug with Vorbis encoder, regression in OggEnc v2.87
* Fixed creation of Monkey's Audio (APE) files, when no meta data is being embedded
* Updated language files (big thank-you to all contributors !!!)

[LoRd_MuldeR]

LameXP v4.13 RC-5

Changes between v4.12 and v4.13 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015
* Apply the original file's "creation" and "last modified" date/time to the output file (optional)
* Updated Vorbis encoder to OggEnc v2.88 (2015-09-10), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.78 (2015-10-02), compiled with ICL 15.0 and MSVC 12.0
* Fixed resampling bug with Vorbis encoder, regression in OggEnc v2.87
* Fixed creation of Monkey's Audio (APE) files, when no meta data is being embedded
* Updated language files (big thank-you to all contributors !!!)

[LoRd_MuldeR]

LameXP v4.13 RC-6

Changes between v4.12 and v4.13 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015
* Apply the original file's "creation" and "last modified" date/time to the output file (optional)
* Updated Vorbis encoder to OggEnc v2.88 (2015-09-10), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.78 (2015-10-02), compiled with ICL 15.0 and MSVC 12.0
* Fixed resampling bug with Vorbis encoder, regression in OggEnc v2.87
* Fixed creation of Monkey's Audio (APE) files, when no meta data is being embedded
* Updated language files (big thank-you to all contributors !!!)

[LoRd_MuldeR]

LameXP v4.13 has been released!
https://github.com/lordmulder/LameXP/releases/latest

Changes between v4.12 and v4.13 [2015-12-12]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-1
* Apply the original file's "creation" and "last modified" date/time to the output file (optional)
* Updated Vorbis encoder to OggEnc v2.88 (2015-09-10), using libvorbis v1.3.5 and aoTuV b6.03_2015
* Updated MediaInfo to v0.7.78 (2015-10-02), compiled with ICL 15.0 and MSVC 12.0
* Fixed resampling bug with Vorbis encoder, regression in OggEnc v2.87
* Fixed creation of Monkey's Audio (APE) files, when no meta data is being embedded
* Updated language files (big thank-you to all contributors !!!)

[manolito]

Thanks LoRd_MuldeR, works beautifully... :thanks:

[Octo-puss]

Portable build please :)

[SeeMoreDigital]

Many thanks :)

[manolito]

Portable build please :)

http://lamexp.sourceforge.net/doc/FAQ.html#9fd53558

Is it really this hard to rename the LameXP executable?


Cheers
manolito

[LoRd_MuldeR]

Portable build please :)

Here we go:
http://sourceforge.net/projects/lamexp/files/Miscellaneous/Special%20Builds/LameXP-PORTABLE.2015-12-12.Release-Static.Build-1852.zip/download

[Octo-puss]

http://lamexp.sourceforge.net/doc/FAQ.html#9fd53558

Is it really this hard to rename the LameXP executable?

Cheers
manolito
I didn't know that.

edit: Actually it's not that simple it seems. The portable version LM posted has very different file size.

[LoRd_MuldeR]

Actually it's not that simple it seems. The portable version LM posted has very different file size.

...probably because I built and packaged that one "manually", while the standard builds are created with my automated deployment script. So it's quite possible that some settings (e.g. EXE compressor) didn't match 100%.

Another reason for different file size is that the compiler/linker could have "optimized out" the function that checks for "portable mode" at runtime, as it now doesn't get called at all. That would only be a few bytes though.

And, of course, the size of a compressed file will always differ to some extent, even if you change the input file only very slightly. It's like rolling the dice again...

[Octo-puss]

Oh ok. So next time I should just download the normal package and simply rename the exe?

[LoRd_MuldeR]

Oh ok. So next time I should just download the normal package and simply rename the exe?

Effect would be the same, yes ;)

[Dogway]

As depicted by the christmas tree on the encode process of 2014's LameXP, it seems you have trackback access to LameXP, so I blocked it with a firewall.
Just wanted to let people know that this program has access to internet, fishy to say the least (no info on this nonconsent action is elaborated on FAQ).

[LoRd_MuldeR]

As depicted by the christmas tree on the encode process of 2014's LameXP, it seems you have trackback access to LameXP, so I blocked it with a firewall.
Just wanted to let people know that this program has access to internet, fishy to say the least (no info on this nonconsent action is elaborated on FAQ).
I have no idea what you want to tell us with "this program has access to internet" or how this could be related to showing a "christmas tree on the encode process" :confused:

And I even have less of an idea what you think you "blocked with a firewall", because the only Internet/network communication LameXP will ever do is for checking for updates. If you don't want that, just don't make it check for updates...

[Dogway]

I have no idea what you want to tell us with "this program has access to internet" or how this could be related to "christmas tree on the encode process" :rolleyes:

And I have even have less of an idea what you think you "blocked with a firewall", because the only Internet/network communication LameXP will ever do is for checking for updates. If you don't want that, just don't check for updates...

For posterity:
http://i.imgur.com/T3XUboKt.png (http://i.imgur.com/T3XUboK.png)

FYI, original here (link (http://3.bp.blogspot.com/-TWmXCURgcQA/UueHPEPIrhI/AAAAAAAAXbI/IlpC5tY55qE/s1600/Captura+LameXP+3.jpg)).

[LoRd_MuldeR]

For posterity:
http://i.imgur.com/T3XUboKt.png (http://i.imgur.com/T3XUboK.png)

FYI, original here (link (http://3.bp.blogspot.com/-TWmXCURgcQA/UueHPEPIrhI/AAAAAAAAXbI/IlpC5tY55qE/s1600/Captura+LameXP+3.jpg)).

So what? How is posting these seemingly random screenshots related to your previous, equally confusing, post? :confused:

(Yes, there is a christmas tree icon in the upper left corner. So far, so obvious. But that's neither a new "feature", nor a particularly interesting one. What's the relevance of pointing this out?)

[Dogway]

What, you wrote a piece of code to show a Christmas tree every 25th of December? for real? Is that another of your hidden easter eggs?

[SeeMoreDigital]

Please give it a rest Dogway!

[real.finder]

sox temp folder didn't change with lamexp temp folder, and if I had low space in c:\ lamexp will encode 12 kb file with ogg and normalization

unless I did it in cmd and put --temp "E:\temp" in sox

[LoRd_MuldeR]

sox temp folder didn't change with lamexp temp folder, and if I had low space in c:\ lamexp will encode 12 kb file with ogg and normalization

unless I did it in cmd and put --temp "E:\temp" in sox

Okay, I was able to observe this behavior with ProcessMonitor. And I think I know why that happens.

LameXP does explicitly set the "working" directory for the SoX process, to the user-selected TEMP directory. However, the function that actually launches the process was overriding the "working" directory to where the EXE file resides ;)

Try with this TEST build please:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2016-01-03/LameXP-ALPHA.2016-01-03.Release-Static.Build-1854.exe/download

[real.finder]

Try with this TEST build please:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2016-01-03/LameXP-ALPHA.2016-01-03.Release-Static.Build-1854.exe/download

this work :)

[x265]

I get an error when i tried to convert. dts audio file to. aac. What should i do?

http://i.cubeupload.com/hIrU7I.jpg

[LoRd_MuldeR]

I get an error when i tried to convert. dts audio file to. aac. What should i do?

http://i.cubeupload.com/hIrU7I.jpg

You already sent me this exact same screenshot via PM. See my reply. Please don't double-post. Thanks!

[SeeMoreDigital]

I've been doing some tests using the DCA encoder (dcaenc-2) and have noticed that when I play the multi-channel encodes using my Oppo and LG television (and pass the bit-stream to my surround sound amplifier) the audio sounds distorted.

I can confirm that the 768Kbps dts encode sounds much less distorted than the 1536Kbps dts encode.

The strange thing is, the same encodes sound fine when played using MPC-BE with LAV!

Any ideas what might be causing this?

[LoRd_MuldeR]

LameXP v4.14 Alpha 2

Changes between v4.13 and v4.14 [unreleased]:
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Enabled the "built-in" resampler for QAAC encoder
* Updated MediaInfo to v0.7.82 (2016-01-27), compiled with ICL 15.0 and MSVC 12.0
* Updated QAAC add-in to the to QAAC v2.58 (2016-01-05)
* Updated ALAC decoder to refalac v1.58 (2016-01-05)

Be sure to grab latest QAAC add-in from here:
http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/LameXP.qaac-addin.2016-01-31.zip/download

[GMJCZP]

A person called Case (foobar2000 forum) has continued to develop fhg aac:

Here (https://hydrogenaud.io/index.php/topic,110211.0.html) and Here (https://www.foobar2000.org/encoderpack)

I tried to LameXP but not working, why it is not compatible?

Edit: these are two files.

[LoRd_MuldeR]

A person called Case (foobar2000 forum) has continued to develop fhg aac:

Here (https://hydrogenaud.io/index.php/topic,110211.0.html) and Here (https://www.foobar2000.org/encoderpack)

I tried to LameXP but not working, why it is not compatible?

Edit: these are two files.

I have identified at leas three problems:

LameXP checks the version string, using the "-help" option. This is working fine with the old "tmkk" version, but the new "Case" version just errors out. No version string is printed!
LameXP checks that all required DLL's are present. The old "tmkk" version required libsndfile-1.dll, but the new "Case" version does not. It still needs the other ones though (enc_fhgaac.dll, nsutil.dll and libmp4v2.dll).
LameXP requires at least version "20120806" of fhgaacenc, but the version from Foobar Encoder Pack reports "20120624" and additionally "20151024". LameXP only looks at the first one, which is too old.


Fix is underway...

[LoRd_MuldeR]

LameXP v4.14 Alpha 3

Changes between v4.13 and v4.14 [unreleased]:
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also effects the QAAC encoder
* Updated MediaInfo to v0.7.82 (2016-01-27), compiled with ICL 15.0 and MSVC 12.0
* Updated QAAC add-in to the to QAAC v2.58 (2016-01-05)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Updated ALAC decoder to refalac v1.58 (2016-01-05)

Be sure to grab latest FhgAacEnc add-in here:
http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/fhgaac/LameXP.fhgaacenc-addin.2016-02-03.zip/download

[GMJCZP]

Thank you! When you can prove it.

Edit: I only see the file fhgaacenc.exe, the other file of Case is not necessary?

[LoRd_MuldeR]

Edit: I only see the file fhgaacenc.exe, the other file of Case is not necessary?

You copy the required DLL's from the Winamp installation directory (or extract them from the Winamp installer via 7-Zip), as described in the included INSTRUCTIONS.txt file ;)

Installing the Visual C++ 2008 Redistributable Package (x86) may be required too...

[GMJCZP]

One more thing: Avast is detecting a threat your last builds (include simple x264), LoRd_MuldeR.

[mariush]

Go to http://www.virustotal.com and upload the application or the executable there. If it's just one or a few antiviruses (out of 20+) complaining there's a high chance there's no actual virus.

[LoRd_MuldeR]

LameXP v4.14 Alpha 4
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2016-02-04/LameXP-ALPHA.2016-02-04.Release-Static.Build-1866.exe/download

Changes between v4.13 and v4.14 [unreleased]:
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also effects the QAAC encoder
* Updated MediaInfo to v0.7.82 (2016-01-27), compiled with ICL 15.0 and MSVC 12.0
* Updated QAAC add-in to the to QAAC v2.58 (2016-01-05)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Updated ALAC decoder to refalac v1.58 (2016-01-05)

Be sure to grab latest FhgAacEnc add-in here:
http://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/fhgaac/LameXP.fhgaacenc-addin.2016-02-03.zip/download

[LoRd_MuldeR]

One more thing: Avast is detecting a threat your last builds (include simple x264), LoRd_MuldeR.

Same old story ;)
http://lamexp.sourceforge.net/doc/Manual.html#anti-virus-notes

BTW: Fixed yet another FhgAacEnc issue...

[LoRd_MuldeR]

LameXP v4.14 Alpha 5
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2016-02-20/LameXP-ALPHA.2016-02-20.Release-Static.Build-1870.exe/download

Changes between v4.13 and v4.14 [unreleased]:
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also effects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.1.2 and Opus-Tools to v0.1.9 (2016-01-12)
* Updated MediaInfo to v0.7.82 (2016-01-27), compiled with ICL 15.0 and MSVC 12.0
* Updated QAAC add-in to the to QAAC v2.58 (2016-01-05)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Updated ALAC decoder to refalac v1.58 (2016-01-05)

[Sparktank]

:thanks: Thanks for continual support.

[LoRd_MuldeR]

LameXP v4.14 Alpha 6

Changes between v4.13 and v4.14 [unreleased]:
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also effects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus encoder/decoder libraries to v1.1.2 and Opus-Tools to v0.1.9 (2016-01-12)
* Updated MediaInfo to v0.7.82 (2016-01-27), compiled with ICL 15.0 and MSVC 12.0
* Updated QAAC add-in to the to QAAC v2.58 (2016-01-05)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Updated ALAC decoder to refalac v1.58 (2016-01-05)

[real.finder]

hi LoRd_MuldeR

I would suggest adding an option to choose between AAC encoders, and the auto choice act like the how lamexp do now except in low bit-rate/Quality or if the HE-AAC v2 is selected lamexp will prefer nero because it better than others in that

QAAC never encode in HE-AAC automatically, and support HE-AAC v1 only (did't support HE-AAC v2)

edit1: in tvbr mode in QAAC I can't encode in HE-AAC, and after I test more I see that QAAC in very low bit-rate (8 kbps) will encode HE-AAC v2 if I choose HE-AAC v1 or HE-AAC v2 ! and in the low (64 kbps) will encode in HE-AAC v1 if I choose HE-AAC v1 or HE-AAC v2 !

edit2: with 48000 Hz even in 8 kbps QAAC will encode HE-AAC v1 if either HE-AAC v1 or HE-AAC v2 chosen

edit3: 8 kbps in QAAC made the output in 32 kbps in 44100 Hz stereo, and in another test I see that in 40 kbps QAAC will encode HE-AAC v1 and in 32 kbps will encode HE-AAC v2 if either HE-AAC v1 or HE-AAC v2 chosen, if I didn't choose HE-AAC v1 nor HE-AAC v2 QAAC will encode in LC

[von Suppé]

Hi LoRd_MuldeR,

First, awesome program, thank you.
I found out that when I convert flac files into mp3, the <track> and <Album Artist> tag info from the flac files are not properly copied to the mp3 tags.
The <track> tag automatically gets 1, 2 3, etc. The <Album Artist> tag stays empty.
I checked the Meta Data and Advanced Options tabs but can't find anything about those.

Cheers
von Suppé

[LoRd_MuldeR]

I found out that when I convert flac files into mp3, the <track> and <Album Artist> tag info from the flac files are not properly copied to the mp3 tags.
The <track> tag automatically gets 1, 2 3, etc. The <Album Artist> tag stays empty.
I checked the Meta Data and Advanced Options tabs but can't find anything about those.

As explained various times before, this is not a simple matter of "copying" the meta tags ;)

It requires to detect the meta tags from the original input file, store them in an internal data structure, and finally re-embed them into the re-encoded file.

And all this needs to work with 17 different decoders and 11 different encoders (187 combinations), which all store different tags in different ways.

Therefore, the internal "meta data" model was designed as the "the lowest common denominator" of what the various different audio formats (encoder/decoders) support.

At this time, the "Album Artist" is not maintained as a separate field in the internal "meta data" model, sorry!

About the "track number" issue: I think you probably have "Position" set to "Generate from list position" on the "Meta Data" tab. If so, then the result is as expected.

[von Suppé]

At this time, the "Album Artist" is not maintained as a separate field in the internal "meta data" model, sorry!Thanks for the explanation, it be so.
About the "track number" issue: I think you probably have "Position" set to "Generate from list position" on the "Meta Data" tab. If so, then the result is as expected.Indeed it was. Doh, I feel stupid. Simply didn't know that "Position" meant track #. Changed it to "Unspecified (copy from source file)" and it works like a charm now :-)

Thank you
von Suppé

[LoRd_MuldeR]

LameXP v4.14 Alpha 8
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2016-04-07/LameXP-ALPHA.2016-04-07.Release-Static.Build-1878.exe/download

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also effects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated Opus encoder/decoder libraries to v1.1.2 and Opus-Tools to v0.1.9 (2016-01-12)
* Updated MediaInfo to v0.7.82 (2016-01-27), compiled with ICL 15.0 and MSVC 12.0
* Updated QAAC add-in to the to QAAC v2.58 (2016-01-05)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Updated ALAC decoder to refalac v1.58 (2016-01-05)

[Yonah]

I'm having an issue with Vorbis Comment tags on Ogg files encoded with LameXP. My source files are FLAC files and have all been properly tagged. However, after encoding with LameXP, all the tags are duplicated with 2 backslashes (\\) except for the year.

For example, if the artist tag in the FLAC file is "Disturbed", the encoded Ogg file is tagged as "Disturbed\\Disturbed." The comment contains "Encoded with LameXP\\", followed by the original comment from the source FLAC file.

This bug does not occur if the Normalization Filter is enabled.

[LoRd_MuldeR]

I'm having an issue with Vorbis Comment tags on Ogg files encoded with LameXP. My source files are FLAC files and have all been properly tagged. However, after encoding with LameXP, all the tags are duplicated with 2 backslashes (\\) except for the year.

For example, if the artist tag in the FLAC file is "Disturbed", the encoded Ogg file is tagged as "Disturbed\\Disturbed." The comment contains "Encoded with LameXP\\", followed by the original comment from the source FLAC file.

This bug does not occur if the Normalization Filter is enabled.

Hello, Yonah.

If the selected encoder is capable of reading the input file format directly (and if no filters are enabled!), then LameXP takes a "shortcut" and just invokes the encoder directly on the input file – instead of going the usual "decoder → filters → encoder" route with intermediate WAV files. Now my guess is that, when OggEnc2 (i.e. the Ogg/Vorbis encoder) is reading your input FLAC file directly, then it keeps the meta tags found in the original FLAC and also appends the tags specified explicitly by LameXP – rather than "replacing" redundant tags. Not sure whether this is a bug or a feature. Enabling the "normalization" filter probably fixes this, because the "shortcut" can no longer be used when filters are enabled ;)

[EDIT]

Okay, I think it's a feature and we need to use the --discard-comments command-line switch of OggEnc2 to get the desired result. A new version is underway...

[Yonah]

Okay, I think it's a feature and we need to use the --discard-comments command-line switch of OggEnc2 to get the desired result. A new version is underway...

Thanks, Lord_Mulder! The command-line switch is just what I needed. Before I moved overseas I ripped my entire CD collection to FLAC. Since I use Vorbis exclusively on my phone this tag issue was problematic for me. No more manual tag editing after I encode an album. :)

[LoRd_MuldeR]

LameXP v4.14 Alpha 9
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2016-04-16/LameXP-ALPHA.2016-04-16.Release-Static.Build-1880.exe/download

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.1.2 and Opus-Tools to v0.1.9 (2016-01-12)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated MediaInfo to v0.7.82 (2016-01-27), compiled with ICL 15.0 and MSVC 12.0
* Updated QAAC add-in to the to QAAC v2.58 (2016-01-05)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Updated ALAC decoder to refalac v1.58 (2016-01-05)

[MCFish]

You already sent me this exact same screenshot via PM. See my reply. Please don't double-post. Thanks!

Hi i need that answer too. Ive got this error on any multichannel file

[LoRd_MuldeR]

Hi i need that answer too. Ive got this error on any multichannel file

Here we go:
I got this error when i tried to convert a. dts audio file to aac. What should i do in order to fix this?

http://i.cubeupload.com/JmcNnL.jpg

Hello.

The problem is that the WAV file (decoded from the input DTS) exceeds a size of 4 GB, which is above the WAV format file size limits. There is nothing that can be done about it :(

Using Wav64 (http://www.ambisonia.com/Members/mleese/sony_wave64.pdf/sony_wave64.pdf) would be an option, if more tools did support it. But they don't. So we are stuck with plain old WAV for now...

BTW:
* http://windows.microsoft.com/en-us/windows/use-snipping-tool-capture-screen-shots#1TC=windows-7
* https://en.wikipedia.org/wiki/Cut,_copy,_and_paste

Regards,
MuldeR

[MCFish]

Ok thanks for quick answer.
But, after i enable qaac in lamexp, qaac encodes the same file with success. Opus encoder still fails. How is that possible?
Tried it twice now, and both success with qaac...
Wav file should still be same size, right?

edit, i saw the 4gb warning in the log....yuck encoded file had a longer playtime...

[LoRd_MuldeR]

The original WAV format, the one that actually has wide support, is limited to 4 GB. Some implementations are even limited to 2 GB, because they interpret the "size" field as signed (the specs don't say it, but only unsigned makes sense).

Then there are the WAVE64 and RF64 formats: While WAVE64 is a proper extension of the WAV standard to 64-Bit and thus what everybody should be using in an ideal world (but not backwards compatible to original WAV), the RF64 format is pretty much a "dirty" hack to allow more than 4 GB in a single WAV file (note: RF64 is nothing but several standard WAV file structures dumped into one contiguous file) and provides at least some backwards compatibly to original WAV.

Now, what happens when the writing application writes a normal WAV files but the size exceeds 4 GB? Some application just fail. Some create a normal WAV file with more than 4 GB of content, which means you get a non-standard (broken) WAV file. And some switch over from WAV to RF64 "on the fly" when the 4 GB limit is exceeded. At least in the latter case there is a certain chance that the reading application will be able to read the file. But there is no guarantee it will work!

(In the end, WAV files larger than 4 GB are always problematic and things may fail on you randomly)

[Sparktank]

human wiki

Thanks for the explaination!
It makes so much more sense now.

It's quite hard to keep track of what actually supports w64 formats these days.
Thankfully, eac3to does. Custom builds of SoX. My eyes.

[mariush]

As a workaround, you may want to try saving to FLAC (lossless, fast compression) to get around the 4 GB limitations of WAV files. Then you can pipe the decoded output from FLAC straight into neroaac or some other audio encoder that supports raw / piped input

[MCFish]

Thanks you all for explaining and posting suggestions to the wav limitation. Guess i just continue to do doublework in Atak's Ripbot

[manolito]

We had this discussion about WAV files > 4GB before in this thread. LoRd_MuldeR made it very clear that he wanted LameXP to be a universal solution, and since other tools used by LXP do not (or only partly) support WAV64 of RF64 there is no way to support the conversion of large multichannel sources.

To me the only workaround was to give up on universality, so I definded some special cases and the corresponding work flows.

Generally the problem occurs for 6-ch (or more than 6) sources with a length of a little over 2 hours. For these cases I needed solutions which did not use intermediate WAV files.

AC3 to AAC:
BeSweet or EAC3To

DTS to AC3 or AAC:
Eac3To

AAC to AC3:
For this I made my own converter which uses FAAD, SoX and Aften. (Neither BeSweet nor Eac3To support AAC input.)
http://forum.doom9.org/showthread.php?p=1616904#post1616904


Of course it can be done differently using FFmpeg (and QAAC with piping).


Cheers
manolito

[Motenai Yoda]

well most tools supports pipe in/out, so maybe using ie sox to do it can be a workaround to feed those tools.

also ffmpeg has its own aac codec, and can be build with libfdk_aac too

[LoRd_MuldeR]

LameXP v4.14 Beta-2

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.1.2 and Opus-Tools to v0.1.9 (2016-05-22)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated MediaInfo to v0.7.85 (2016-04-29), compiled with ICL 15.0 and MSVC 12.0
* Updated QAAC add-in to the to QAAC v2.58 (2016-01-05)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Updated ALAC decoder to refalac v1.58 (2016-01-05)
* Improved auto-update function (faster Internet connectivity check)

[GMJCZP]

Hi LordMulder:

In February formatted my pc and 4.13 LameXP had not installed. I switched from avast to avg and now the program only runs disabling the antivirus. If active the antivirus the pc hangs me, not even placing .exe exclusions works.
I like very much this program but clarify that I have no intention of changing AV, sorry. I have WXP SP3.

[mike20021969]

...avg and now the program only runs disabling the antivirus.,.. I have WXP SP3.I'm running Windows XP SP3 with AVG Free (I'm using the 2012 version as 2013 onwards gave a BSOD EVERY time during install). LameXP even with AVG active works fine. Launches in <5 seconds.

[GMJCZP]

I'm running Windows XP SP3 with AVG Free (I'm using the 2012 version as 2013 onwards gave a BSOD EVERY time during install). LameXP even with AVG active works fine. Launches in <5 seconds.

2012? Why? :scared:

I have last version offline updated.

[mike20021969]

2012? Why? :scared:As I said "2013 onwards gave a BSOD EVERY time during install".

[LoRd_MuldeR]

I like very much this program but clarify that I have no intention of changing AV, sorry. I have WXP SP3.

Well, it's your decision to stick with a buggy anti-virus software, even if it means that you cannot use legitimate applications.

Personally, I can not recommend to accept this new form of censorship though.

(Technically there nothing I can do on my side - unless they showed me the exact line of code in my program that justifiably classifies as "malware" behavior - which of course doesn't exist)

[GMJCZP]

IMHO, change a AV to run a program would put the garbage under the carpet.
If you are interested, Simplex264 serves me right, but by LameXP, spend several times in the Recovery Console with chkdsk /p yesterday was unpleasant.
If the manufacturer does not listen to a client nothing can be done.

It's a shame, because your programs are good. Maybe that's the problem.

[LoRd_MuldeR]

IMHO, change a AV to run a program would put the garbage under the carpet.

In what way ???

The so-called "anti-virus" software blocks a program that, without the slightest doubt, is 100% legitimate (if you want say the opposite, then show me the exact lines of code in my program that unambiguously classify "malware" behavior"), so the bug/problem is in the anti-virus software! Consequently the one and only place where the bug could be fixed is the anti-virus software. Because anti-virus software is a "blackbox" and they keep their algorithms secret, any kind of speculation why anti-virus software XYZ is failing horribly this time is totally pointless. Especially because there is a zillion of anti-virus softwars out there and because their behvious can (and most often will) change with the next update.

NOTE: You have to understand that "FALSE POSITIVES" are an important part of the business model of anti-virus companies. They sell "premium" contracts to the big software companies, so the programs of those companies get "whitelisted" immediately. If there wasn't a sufficiently high probability that 100% legitimate programs get blocked due to "FALSE POSITIVES", then this business model wouldn't work. Of course it means that if you are not one of those big companies, you stuff just gets censored! That's how blackmail works in the 21st century. For independent software developers and smaller companies this has become a HUGE problem. I also work on a couple of commercial projects, so I know what I'm talking about...

(Buying an EV software-signing certificates helps, to some degree, but the price is WAY beyond what I can afford for my hobby projects. Let alone that you need to be a registered business in order to get this kind of certificate)

[GMJCZP]

In this moment I use AVG free. I don't have internet in my pc, so it's enough for me.

[lethedoom]

In this moment I use AVG free. I don't have internet in my pc, so it's enough for me.
also,"Hi LordMulder:

In February formatted my pc and 4.13 LameXP had not installed. I switched from avast to avg and now the program only runs disabling the antivirus. If active the antivirus the pc hangs me, not even placing .exe exclusions works.
I like very much this program but clarify that I have no intention of changing AV, sorry. I have WXP SP3.
__________________
By law and justice!

RescueFrame"

http://finance.yahoo.com/news/avast-announces-agreement-acquire-avg-063000656.html

What will you do ?

[Randy31416]

4.13 introduced a buglet in file naming that I believe 4.12 did not have. I have the advanced option "Rename Output Files" unchecked (no checkmark) so file names should not be changed. Yet a buch of filenames are changed. All of them end in a period -- file names such as "Maestro E.K.E." or "Wach uff myn Hört etc." that are created by another program reading external sources. The filetype I am using is ".wav", and the files are being converted to ".mp3". When a filename ends in a period, the period is stripped during conversion. So, for example, "M:\Music\For Ellington\Maestro E.K.E..wav" does not become "M:\Music\For Ellington\Maestro E.K.E..mp3" but becomes "M:\Music\For Ellington\Maestro E.K.E.mp3" instead. I do note that double internal spaces are now preserved, but I persist in thinking that not checking "rename output files" should mean that I get out the same name I put in.

[LoRd_MuldeR]

Randy31416, this is because the clean_file_name() function is applied to clean up the file name, before the final file extension is appended. And dots (.) at the end of the file name are forbidden, so they are removed.

I have changed the logic now, so that the clean up function gets applied at a slightly later point:
https://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-BETA.2016-07-17.Release-Static.Build-1896.exe/download

[Randy31416]

I have changed the logic now, so that the clean up function gets applied at a slightly later pointYou do support this program exceptionally well. Thanks. Randy

[LoRd_MuldeR]

LameXP v4.14 Beta-4

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.1.2 and Opus-Tools to v0.1.9 (2016-05-22)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated MediaInfo to v0.7.85 (2016-04-29), compiled with ICL 15.0 and MSVC 12.0
* Updated QAAC add-in to the to QAAC v2.58 (2016-01-05)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Updated mpg123 decoder to v1.23.4 (2016-05-11), compiled with GCC 5.3.0
* Updated ALAC decoder to refalac v1.58 (2016-01-05)
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Improved auto-update function (faster Internet connectivity check)

[LoRd_MuldeR]

LameXP v4.14 Beta-5

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.1.3 and Opus-Tools to v0.1.9 (2016-09-11)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated MediaInfo to v0.7.85 (2016-04-29), compiled with ICL 15.0 and MSVC 12.0
* Updated QAAC add-in to the to QAAC v2.58 (2016-01-05)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Updated mpg123 decoder to v1.23.4 (2016-05-11), compiled with GCC 5.3.0
* Updated ALAC decoder to refalac v1.58 (2016-01-05)
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Improved auto-update function (faster Internet connectivity check)

[LoRd_MuldeR]

The QAAC Add-in has been updated to QAAC v2.61:
LameXP.qaac-addin.2016-10-03.zip (https://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/LameXP.qaac-addin.2016-10-03.zip/download)

[LoRd_MuldeR]

LameXP v4.14 Beta-7

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.1.3 and Opus-Tools to v0.1.9 (2016-09-11)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated MediaInfo to v0.7.88 (2016-08-31), compiled with ICL 15.0 and MSVC 12.0
* Updated QAAC add-in to the to QAAC v2.61 (2016-10-02)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Updated mpg123 decoder to v1.23.4 (2016-05-11), compiled with GCC 5.3.0
* Updated ALAC decoder to refalac v1.61 (2016-10-02)
* Updated WavPack decoder to v4.80.0 (2016-03-28), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Improved auto-update function (faster Internet connectivity check)

[LoRd_MuldeR]

LameXP v4.14 RC-1

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.1.3 and Opus-Tools to v0.1.9 (2016-10-16)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated FLAC encoder/decoder to v1.3.1 (2016-10-04), compiled with ICL 17.0 and MSVC 12.0
* Updated MediaInfo to v0.7.88 (2016-08-31), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.23.4 (2016-05-11), compiled with GCC 5.3.0
* Updated ALAC decoder to refalac v1.61 (2016-10-02)
* Updated WavPack decoder to v4.80.0 (2016-03-28), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Updated QAAC add-in to the to QAAC v2.61 (2016-10-02)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Improved auto-update function (faster Internet connectivity check)

[LoRd_MuldeR]

LameXP v4.14 RC-2

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.1.3 and Opus-Tools to v0.1.9 (2016-10-16)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated FLAC encoder/decoder to v1.3.1 (2016-10-04), compiled with ICL 17.0 and MSVC 12.0
* Updated MediaInfo to v0.7.88 (2016-08-31), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.23.8 (2016-09-27), compiled with GCC 6.2.0
* Updated ALAC decoder to refalac v1.61 (2016-10-02)
* Updated WavPack decoder to v4.80.0 (2016-03-28), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Updated QAAC add-in to the to QAAC v2.61 (2016-10-02)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Improved auto-update function (faster Internet connectivity check)
* Updated language files (big thank-you to all contributors !!!)

[digitaltoast]

Looking good, but if you're after feedback on 4.14RC2, I just have a couple:

During install, it wants to install to folder 4.11 and won't let me change path.
When encoding mp3, even when I override the samplerate and enforce 44.1KHz, it downgrades to 32KHz etc, at anything above VBR compression level 6.

That's it, so far! Do you need screenshots or is that OK? Thanks for a great app!

[LoRd_MuldeR]

During install, it wants to install to folder 4.11 and won't let me change path.

That's because the installer will "upgrade" the existing installation - which is located wherever you originally installed LameXP.

When encoding mp3, even when I override the samplerate and enforce 44.1KHz, it downgrades to 32KHz etc, at anything above VBR compression level 6.

And that's because of LAME's psycho-acoustic model.

The sampling rate determines the highest frequency that can be retained (cf. Nyquist–Shannon sampling theorem (https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem)). So, by reducing the sampling rate from 44.1 kHz to 32 kHz, you are effectively low-pass filtering the audio. In other words, the highest frequencies are discarded before the actual encoding. At a sampling frequency of 44.1 kHz the highest audio frequency that can be retained (without aliasing) is 22.05 kHz; at a sampling frequency of 32 kHz, the highest audio frequency that can be retained is 16 kHz. Low-pass filtering the audio makes a lot of sense at very low bitrates (or the lowest VBR quality levels), because loosing the highest frequencies is way less disturbing than the compression artifacts that arise otherwise.

Note: It's possible to "force" LAME to encode at the original sampling rate, by explicitly specifying the "--resample" option with the original sampling rate. But you almost always do not want this!

[digitaltoast]

Many thanks for the explanation:

Note: It's possible to "force" LAME to encode at the original sampling rate, by explicitly specifying the "--resample" option with the original sampling rate. But you almost always do not want this!

Except of course when it's a particularly archaic piece of hardware which can only cope with multiples of 11.020 :)

Perfect, thank you.

[LoRd_MuldeR]

Except of course when it's a particularly archaic piece of hardware which can only cope with multiples of 11.020 :)

Just for the notes: The original MP3 (actually "MPEG-1 Audio Layer III") specification from 1993 defines three possible sampling rates – 48 kHz, 44.1 kHz and 32 kHz – that any "compliant" decoder must support.

(More sampling rates – 16 kHz, 22.05 kHz and 24 kHz – have been added to MP3 with the MPEG-2 standard in 1995)

[RieGo]

in the latest version (RC2) it seems that opus isn't working properly. if i encode with the same setting as before (VBR 16kbps; complexity 10; framesize 60) i get valid opus files with correct filesize, but when played back it's just extremely noisy, which sounds like compressed at 1kbps :)
anyways, keep up the good work!

[LoRd_MuldeR]

in the latest version (RC2) it seems that opus isn't working properly. if i encode with the same setting as before (VBR 16kbps; complexity 10; framesize 60) i get valid opus files with correct filesize, but when played back it's just extremely noisy, which sounds like compressed at 1kbps :)
anyways, keep up the good work!

I see what you mean. I tried encoding a piece of music at ~16 kbps and it came out as total noise. Not that I would expect anything worthwhile at ~16 kbps.

Interestingly, at ~24 kbps it came out "okay". Of course, the ~24 kbps version didn't sound very good either. But considering that it's only ~24 kbps Opus still performed pretty well at that rate. Nothing like the ~16 kbps result.

I'm not sure whether the ~16 kbps result is a bug in latest Opus or just what you have to expect at that ultra-low rate. If you got better result before, with what Opus version was that? :confused:

[RieGo]

I see what you mean. I tried encoding a piece of music at ~16 kbps and it came out as total noise. Not that I would expect anything worthwhile at ~16 kbps.

Interestingly, at ~24 kbps it came out "okay". Of course, the ~24 kbps version didn't sound very good either. But considering that it's only ~24 kbps Opus still performed pretty well at that rate. Nothing like the ~16 kbps result.

I'm not sure whether the ~16 kbps result is a bug in latest Opus or just what you have to expect at that ultra-low rate. If you got better result before, with what Opus version was that? :confused:

yes! i use opus mainly to encode tons of audiobooks (mono), which results in "really good" sound quality starting at 16kbps. it worked just fine on releases before RC2 (or RC1?) and it also works with official opus encoder 1.1.3.
if you say 24kbps came out okay for you, it may be just a problem on my side. i'll try to reinstall LameXP and check.

update:
same problem after reinstalling and removing settings.
i uploaded 2 samples, so you know what i mean:
03_opusenc.opus (https://mega.nz/#!ssAX2BzS!N9SXRhmDMtiO7cfNqV0Ujb0oaYFi9e4M0B3UHAyPBAo)
03_RC2.opus (https://mega.nz/#!I5Bgya6Y!UaA4FNFht69HAMef0U5NdcYMFvfjUIgWYjtSdBUTAkE)

i also tried encoding at 24kbps and 128kbps:
24kbps has the same weird artifacts, but not as present as with lower bitrate
128kbps sounds just fine

maybe it's really just a bug in the latest Opus, which effects only lowest bitrates

btw: i have seen that opus files generated by LameXP are always 1kbps lower than set. so i encoded my sample at 15kbps with opusenc

[LoRd_MuldeR]

yes! i use opus mainly to encode tons of audiobooks (mono), which results in "really good" sound quality starting at 16kbps. it worked just fine on releases before RC2 (or RC1?) and it also works with official opus encoder 1.1.3.

Opus binaries have last been updated in RC-1, from Git "master" 2016-09-11 to 2016-10-16. There has not been any change to Opus between RC-1 and RC-2.


maybe it's really just a bug in the latest Opus, which effects only lowest bitrates

I noticed two recent commits/fixes that may be related to this problem: https://git.xiph.org/?p=opus.git;a=commit;h=6d0628493550f4ef0eaecf3058a502404bc6dca2
https://git.xiph.org/?p=opus.git;a=commit;h=2af92cd99f1f78f596a49dc951d17faeb9363dd3

Will try building latest version soon... (not this weekend though)


btw: i have seen that opus files generated by LameXP are always 1kbps lower than set. so i encoded my sample at 15kbps with opusenc

By default, Opus uses VBR mode. So, by default, the selected bitrate only "specifies the average rate for a large and diverse collection of audio". It's more a rough estimate.

Your particular audio file may, very well, come out at a somewhat higher or a somewhat lower average bitrate!

If you really whish to hit a specific average bitrate, then you have to add the "--cvbr" option, aka "constrained variable bitrate encoding". Or even use the "--hard-cbr" option.

[LoRd_MuldeR]

RieGo, can you please try again with the latest LameXP build?
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2016-10-30/LameXP-RC3.2016-10-30.Release-Static.Build-1924.exe/download

(After some testing, it appears that the "noisy" output occurs when SSE2 or AVX compiler-optimizations are enabled for the Opus library, so I keep them disabled for now. The recent fixes in Opus code seem unrelated)

[amayra]

i try to convert m4a " dash" but lamexp tell me this is not supported format ?
source form youtube

[LoRd_MuldeR]

i try to convert m4a " dash" but lamexp tell me this is not supported format ?
source form youtube

What does MediaInfo say about that file?
https://github.com/lordmulder/mediainfo-gui/releases/latest

[RieGo]

RieGo, can you please try again with the latest LameXP build?
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2016-10-30/LameXP-RC3.2016-10-30.Release-Static.Build-1924.exe/download

(After some testing, it appears that the "noisy" output occurs when SSE2 or AVX compiler-optimizations are enabled for the Opus library, so I keep them disabled for now. The recent fixes in Opus code seem unrelated)

your new release works just fine. thanks a lot!

[amayra]

General
Complete name : D:\Downloads\Music\videoplayback_15.m4a
Format : dash
Codec ID : dash (iso6/mp41)
File size : 3.70 MiB
Duration : 4 min 4 s
Overall bit rate : 127 kb/s
Encoded date : UTC 2016-10-29 07:49:10
Tagged date : UTC 2016-10-29 07:49:10

Audio
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 4 min 4 s
Bit rate : 126 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 spf)
Compression mode : Lossy
Stream size : 3.66 MiB (99%)
Encoded date : UTC 2016-10-29 07:49:10
Tagged date : UTC 2016-10-29 07:49:10

[ggtop]

nice :D

ggtop

[LoRd_MuldeR]

General
Complete name : D:\Downloads\Music\videoplayback_15.m4a
Format : dash
Codec ID : dash (iso6/mp41)

Despite .m4a file extensions, this is actually not normal MP4 format, but DASH (Dynamic Adaptive Streaming over HTTP).

It appears that the FAAD decoder, as used by LameXP, does not support DASH format, so simply adding "dash" to the list of supported formats wouldn't help.

However, passing the file trough MP4Box (https://www.sendspace.com/file/1ts5nr) once seems to "fix" the file, so that LameXP (FAAD) can handle it:
mp4box.exe -add videoplayback_15.m4a -new videoplayback_15.FIXED.mp4

[LoRd_MuldeR]

LameXP v4.14 RC-4

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.2-alpha and Opus-Tools to v0.1.9 (2016-11-02)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated FLAC encoder/decoder to v1.3.1 (2016-10-04), compiled with ICL 17.0 and MSVC 12.0
* Updated MediaInfo to v0.7.88 (2016-08-31), compiled with ICL 15.0 and MSVC 12.0
* Updated mpg123 decoder to v1.23.8 (2016-09-27), compiled with GCC 6.2.0
* Updated ALAC decoder to refalac v1.61 (2016-10-02)
* Updated WavPack decoder to v4.80.0 (2016-03-28), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Updated QAAC add-in to the to QAAC v2.61 (2016-10-02)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Improved auto-update function (faster Internet connectivity check)

[LoRd_MuldeR]

LameXP v4.14 RC-5

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.2-alpha and Opus-Tools to v0.1.9 (2016-11-04)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated FLAC encoder/decoder to v1.3.1 (2016-10-04), compiled with ICL 17.0 and MSVC 12.0
* Updated MediaInfo to v0.7.90 (2016-10-31), compiled with ICL 17.0 and MSVC 12.0
* Updated mpg123 decoder to v1.23.8 (2016-09-27), compiled with GCC 6.2.0
* Updated ALAC decoder to refalac v1.61 (2016-10-02)
* Updated WavPack decoder to v4.80.0 (2016-03-28), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Updated QAAC add-in to the to QAAC v2.61 (2016-10-02)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Improved auto-update function (faster Internet connectivity check)

[LoRd_MuldeR]

LameXP v4.14 RC-6

Changes between v4.13 and v4.14 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Fixed encoding of non-Stereo sources with NeroAAC, when "HE-AAC v2 (SBR+PS)" is selected
* Fixed a bug that would cause the encoding job to fail, when an audio filter is skipped
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.2-alpha and Opus-Tools to v0.1.9 (2016-11-04)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated FLAC encoder/decoder to v1.3.1 (2016-10-04), compiled with ICL 17.0 and MSVC 12.0
* Updated MediaInfo to v0.7.90 (2016-10-31), compiled with ICL 17.0 and MSVC 12.0
* Updated mpg123 decoder to v1.23.8 (2016-09-27), compiled with GCC 6.2.0
* Updated ALAC decoder to refalac v1.61 (2016-10-02)
* Updated WavPack decoder to v4.80.0 (2016-03-28), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Updated QAAC add-in to the to QAAC v2.61 (2016-10-02)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Improved auto-update function (faster Internet connectivity check)

[LoRd_MuldeR]

LameXP v4.14 Final
https://sourceforge.net/projects/lamexp/files/latest/download

Changes between v4.13 and v4.14 [2016-11-19]:
* Upgraded build environment to Microsoft Visual Studio 2015 with Update-2
* Fixed the location of temporary intermediate files for SoX-based audio effects
* Fixed embedding of meta tags with OggEnc2 when reading directly from OGG/FLAC input file
* Fixed encoding of non-Stereo sources with NeroAAC, when "HE-AAC v2 (SBR+PS)" is selected
* Fixed a bug that would cause the encoding job to fail, when an audio filter is skipped
* Enabled the "built-in" resampler for QAAC encoder
* The "Algorithm Quality" slider now also affects the QAAC encoder
* Added "AVX" (Advanced Vector Extensions) to CPU feature detection code
* Updated Opus encoder/decoder libraries to v1.2-alpha and Opus-Tools to v0.1.9 (2016-11-04)
* Updated LAME encoder to v3.100 Alpha-2 (2016-01-29), compiled with ICL 15.0 and MSVC 12.0
* Updated FLAC encoder/decoder to v1.3.1 (2016-10-04), compiled with ICL 17.0 and MSVC 12.0
* Updated MediaInfo to v0.7.90 (2016-10-31), compiled with ICL 17.0 and MSVC 12.0
* Updated mpg123 decoder to v1.23.8 (2016-09-27), compiled with GCC 6.2.0
* Updated ALAC decoder to refalac v1.61 (2016-10-02)
* Updated WavPack decoder to v4.80.0 (2016-03-28), compiled with ICL 15.0 and MSVC 12.0
* Updated GnuPG to v1.4.21 (2016-08-17), compiled with GCC 6.1.0
* Updated QAAC add-in to the to QAAC v2.61 (2016-10-02)
* Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
* Improved auto-update function (faster Internet connectivity check)
* Updated language files (big thank-you to all contributors !!!)

[manolito]

Thanks very much for the new version... :thanks:

Did a couple of quick tests, no problems so far. I still have to change my desktop colors to 16bit (the newer build environment did not change this).

One question about the FHG AAC encoder add-in:
In the change log I found this:
Updated FhgAacEnc add-in to "Case" edition (2015-10-24)
But the manual does not even mention the FHG encoder, and on your website I could only find ancient FHG add-ons from 2012.

This old FHG add-in does no longer work, so it would be nice if you could provide a link and instructions for this new "Case" edition.


Cheers
manolito

[manolito]

Looks like I spoke too soon...

I have massive problems loading source files into LameXP. I frequently get this window:
http://www77.zippyshare.com/scaled/GMR9KHOk/file.html (http://www77.zippyshare.com/v/GMR9KHOk/file.html)

This happens with MP3 and WAV sources so far (have not tested other formats yet). All my other audio converters work just fine with these files. And the real funny thing is that if I copy such a source file in Explorer to the same location (the new file name will be "Copy Of ...") then LameXP will accept this file without errors.

Looks like a bug to me...


Cheers
manolito

[LoRd_MuldeR]

One question about the FHG AAC encoder add-in:
In the change log I found this:

But the manual does not even mention the FHG encoder, and on your website I could only find ancient FHG add-ons from 2012.

This old FHG add-in does no longer work, so it would be nice if you could provide a link and instructions for this new "Case" edition.

See here:
https://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/fhgaac/

Please follow closely the INSTRUCTIONS to set up everything as needed. You'll need to find a download of Winamp and "borrow" the required files.


I have massive problems loading source files into LameXP. I frequently get this window:
http://www77.zippyshare.com/scaled/GMR9KHOk/file.html (http://www77.zippyshare.com/v/GMR9KHOk/file.html)

This happens with MP3 and WAV sources so far (have not tested other formats yet). All my other audio converters work just fine with these files. And the real funny thing is that if I copy such a source file in Explorer to the same location (the new file name will be "Copy Of ...") then LameXP will accept this file without errors.

This sounds strange, indeed :confused:

There has not been any noteworthy change to the file analysis code since the previous release. But, as always, the MediaInfo binary has been updated to the latest version.

So, what does MediaInfo.exe (https://sourceforge.net/projects/muldersoft/files/MediaInfo%20%28CLI%2BGUI%29/MediaInfo-CLI.2016-11-04.zip/download) have to say when you run it directly and let it analyze the file, from its original path? Does changing the file's path affect MediaInfo's output in some way?

And, most important, what does the log (http://lamexp.sourceforge.net/doc/Manual.html#diagnostic-output) say?

(BTW: Just added ~4700 MP3 files without problem. Any chance you are running some "Anti-Virus" crap that might be interfering?)

[SeeMoreDigital]

Looks like I spoke too soon...

I have massive problems loading source files into LameXP. I frequently get this window:
http://www77.zippyshare.com/scaled/GMR9KHOk/file.html (http://www77.zippyshare.com/v/GMR9KHOk/file.html)

This happens with MP3 and WAV sources so far (have not tested other formats yet).
That's odd...

I've just tried inputting a couple of .wav and .mp3 files (with and without meta-data) and not had any problems. It's all good :)

Cheers and thanks LoRd_MuldeR

[Taurus]

That's odd...

I've just tried inputting a couple of .wav and .mp3 files (with and without meta-data) and not had any problems. It's all good :)

Cheers and thanks LoRd_MuldeR
The same here :thanks: o' Lord

[manolito]

Meanwhile I had gone back to the older stable version 4.13 (which of course fixed the problem). Now I reinstalled 4.14 again, but I got the same problems.

And no, there is no resident AV software on my computer (slows it down too much... :D )

I used WAV files for my tests to rule out any MP3 MetaData problems. Looks like the built-in MediaInfo version does not like my ancient Non-SSE2 CPU and/or my WinXP.

When I run "lxp_mediainfo.exe" from the temp folder, it does not crash, but the output is totally garbled and unreadable. My OS is set to German and Codepage 850.

Here is the debug output of LameXP with a WAV file and a copy of the same file:

Analyzing: I:/01 Untitled 01.wav
Rejected file of unknown type: I:/01 Untitled 01.wav
All files added.

Analyzing: I:/Kopie von 01 Untitled 01.wav
All files added.


Cheers
manolito


//EDIT//
Renaming the rejected file to "test.wav" did not change anything, the file was still rejected

[SeeMoreDigital]

Does MediaInfo read your .wav contained file? If-so please post what it reports, in full, as a 'text' file?


Cheers

[LoRd_MuldeR]

I used WAV files for my tests to rule out any MP3 MetaData problems. Looks like the built-in MediaInfo version does not like my ancient Non-SSE2 CPU and/or my WinXP.

It does work fine on my Windows XP with SP-3 test system. I don't have a machine with non-SSE2 processor though, because my old Athlon XP died a few years ago.

Anyway, the "i386" MediaInfo binary, that is included with LameXP, was compiled with the /IA32 compiler switch and therefore is supposed to work on all 32-Bit x86 processors.

The only other MediaInfo binary included with LameXP is the "x64" one - which wouldn't even launch on your computer. So, LameXP obviously must be using the "i386" one.

When I run "lxp_mediainfo.exe" from the temp folder, it does not crash, but the output is totally garbled and unreadable. My OS is set to German and Codepage 850.

Can you please do mediainfo.exe "c:\some path\some file.wav" > output.txt and provide the resulting "output.txt" file?

If latest MediaInfo is not working on your machine, how can changing the file's path make any difference? :confused:

Here is the debug output of LameXP with a WAV file and a copy of the same file:

If MediaInfo output is "garbled" already, it is clear that LameXP won't be able to parse it.

[manolito]

The following command:
lxp_mediainfo.exe "c:\test\Kopie von 01 Untitled 01.wav" >i:\output.txt

always produces an "output.txt" file with a size of 0 bytes. No matter if I use a source file which is recognized by LameXP or if I use a file which is rejected.

And my installed MediaInfo version 7.90 produces the following results:

Allgemein
Vollständiger Name : C:\test\test.wav
Format : Wave
Dateigröße : 41,7 MiB
Dauer : 4min 7s
Modus der Gesamtbitrate : konstant
Gesamte Bitrate : 1 411 Kbps

Audio
Format : PCM
Format-Einstellungen für Endianess : Little
Format-Einstellungen für Sign : Signed
Codec-ID : 1
Dauer : 4min 7s
Bitraten-Modus : konstant
Bitrate : 1 411,2 Kbps
Kanäle : 2 Kanäle
Samplingrate : 44,1 KHz
BitDepth/String : 16 bits
Stream-Größe : 41,7 MiB (100%)



Allgemein
Vollständiger Name : C:\test\Kopie von 01 Untitled 01.wav
Format : Wave
Dateigröße : 41,7 MiB
Dauer : 4min 7s
Modus der Gesamtbitrate : konstant
Gesamte Bitrate : 1 411 Kbps

Audio
Format : PCM
Format-Einstellungen für Endianess : Little
Format-Einstellungen für Sign : Signed
Codec-ID : 1
Dauer : 4min 7s
Bitraten-Modus : konstant
Bitrate : 1 411,2 Kbps
Kanäle : 2 Kanäle
Samplingrate : 44,1 KHz
BitDepth/String : 16 bits
Stream-Größe : 41,7 MiB (100%)

As you can see the results are identical for the rejected file (test.wav) and the accepted file.

[manolito]

OK guys, I am throwing in the towel...

I went back to the previous stable version 4.13, and I will consider this version as static as far as I am concerned. Looking at the change log I do not think that I am giving up on anything. Most audio encoders are quite mature, at least the ones I use have not improved significantly over the last 2 years. And the old LameXP shortcomings (not being able to convert large multi-channel files where the intermediate WAV file is larger than 2GB) are the same in the latest version.

This post from the FFmpeg forum sums up my feelings about using older computers and Operating Systems quite perfectly:
https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=2&t=2937&start=10#p11608

Newer is NOT always better... :devil:
But of course I am aware that I am one of the very few people who see it that way. So I will stop to annoy you with my requests to make your software compatible with my hardware and OS.

And this will be my last post within this thread...


Cheers
manolito

[LoRd_MuldeR]

FWIW, today I installed a Windows XP inside a Bochs-based VM, with Pentium 3 emulation. The latest MediaInfo crashed with exception code 0xC000001D (STATUS_ILLEGAL_INSTRUCTION).

:angry:

[LoRd_MuldeR]

FWIW, today I installed a Windows XP inside a Bochs-based VM, with Pentium 3 emulation. The latest MediaInfo crashed with exception code 0xC000001D (STATUS_ILLEGAL_INSTRUCTION).

:angry:

And yeah, my previous MediaInfo build works fine on the same VM. Smells fishy...

(investigating)

[SeeMoreDigital]

And yeah, my previous MediaInfo build works fine on the same VM. Smells fishy...

(investigating)The joys of XP eh ;)

[LoRd_MuldeR]

The joys of XP eh ;)

More the joys of compilers generating SSE2 (or higher) instructions when they are supposed to not do ;)

[jpsdr]

Could it be that the code use intrinsic...? In that case, the instructions are generated, and maybe there is not even a warning in the compiler.

[LoRd_MuldeR]

Could it be that the code use intrinsic...? In that case, the instructions are generated, and maybe there is not even a warning in the compiler.

I don't think MediaInfo recently started using SSE2 intrinsics. Especially since he said that the "installed version" (probably: official binaries) of MediaInfo works okay.

Suspecting a compiler bug. Wouldn't be the first time a compiler generates "enhanced" instructions when it shouldn't...

[K.i.N.G]

Anyone know if it is possible to convert an 7.1 atmos track to AAC 7.1 with atmos?
Or do only True-HD and DTS:x support atmos data?

[SeeMoreDigital]

Anyone know if it is possible to convert an 7.1 atmos track to AAC 7.1 with atmos?
Or do only True-HD and DTS:x support atmos data?In short... No it's not possible to do what you require!

Currently the spatial/object based 'meta-data' information can only be processed and decoded by dedicated Dolby and DTS hardware decoder chip-sets.

[LoRd_MuldeR]

Here is a new TEST build:
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2016-12-16/LameXP-ALPHA.2016-12-26.Release-Static.Build-1950.exe/download

This should fix the MediaInfo issues some people have been experiencing on processors without SSE2 support (it appears that runtime CPU dispatching is severely broken for such processors, so I don't use it anymore).

[sebus]

What are the options to encode .wav to ALAC .mp4 with qaac64

Adding the option to advanced for qaac --alac gives the error as the options are exclusive

I see no logical checkbox for alac only

sebus

[LoRd_MuldeR]

What are the options to encode .wav to ALAC .mp4 with qaac64

Adding the option to advanced for qaac --alac gives the error as the options are exclusive

I see no logical checkbox for alac only

sebus

Sorry, there is no option for encoding to ALAC format, but you can encode from ALAC format.

What would be the reason to encode to ALAC, when you have FLAC available?

FLAC is a completely open format, it is the de-facto standard for lossless audio with very good support in soft- and hardware (while ALAC is rare outside the Apple universe), it compresses at least as good as ALAC, and it's faster than ALAC:
http://wiki.hydrogenaud.io/index.php?title=Lossless_comparison#Comparison_Table

[sebus]

I have old gen 4 iPod (converted from 40Gb HDD to 64Gb SD) connected to Onkyo Receiver via Universal Port, iPod means no flac

And while I can play flac from USB or DLNA server, having local old iPod loaded with various alac files is yet another option

Oh well, I can do conversion with a batch file after all, but having it included in LXP would be helpful

sebus

[SeeMoreDigital]

Welcome to the wonderful 'limited world' of Apple playback devices :scared:

[quitemice]

First of all i want to say that i use and like this excellent program very much!! it does what it is supposed to do, and it works excellent!

But i have a few issues with it, although that aren't issues with the working of this program.

1. I want to know why you choose to unpack the necessary codecs etc from the main executable every time you start the program? In my opinion this is unnecessary? especially on ssd?

2. Why are the settings not saved when upgrading the program with a new version? I know the settings are written to the new config file but the program apparently doesn't use it? every time i update this program the settings are gone and i have to re do all the settings i made.

3. would you consider to remove the sound effects? or disable them by default?

I know this program is opensource and i could make my own version but i'm not skilled enough to do that.

I'm NOT criticizing your work though

[LoRd_MuldeR]

1. I want to know why you choose to unpack the necessary codecs etc from the main executable every time you start the program? In my opinion this is unnecessary? especially on ssd?

Because it gives a very nice "all in one" application that just works "out of the box" and doesn't depend on anything. This way LameXP can also be used as a "portable" application. The user doesn't need to bother that some temporary files get extracted on startup (and will ne cleaned-up automatically on application shutdown), as it is completely transparent to the user. Most users probably never notice.

Especially with SSD, the extraction should be extremely fast. Takes less than a second on my system! If you ever see LameXP to take more than a few seconds to startup up, get rid of the crappy A/V software that is responsible!
http://lamexp.sourceforge.net/doc/Manual.html#performance-issues

(And please don't tell me that LameXP causes your SSD to "wear out" more quickly. SSD's wearing out quickly is a common myth, maybe a problem of the very earliest SSD's, but certainly not of today's ones - as tests have shown many times)


2. Why are the settings not saved when upgrading the program with a new version? I know the settings are written to the new config file but the program apparently doesn't use it? every time i update this program the settings are gone and i have to re do all the settings i made.

Settings are not "not saved", but stored separately for each major release. That's because new major releases can add new settings, removed old settings, or change the meaning of existing settings.

IMO it's better to keep things separate. If you changed any of the defaults in LameXP, then you can do so again in 10 seconds. Any maybe, in the meantime, you realized that you should stick with the defaults anyway...

You can even edit the INI file and rename the INI section from "old" to "new" version, so that the "new" version will try to read your "old" settings. That's on your own risk, of course ;)


3. would you consider to remove the sound effects? or disable them by default?

There are no plans to disable the sounds by default. You can disable them at any time though, if you don't like them.

[LoRd_MuldeR]

LameXP v4.15 Beta-1
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2017-03-25/LameXP-BETA.2017-03-25.Release-Static.Build-1958.exe/download

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-alpha2 (2017-03-03) and Opus-Tools to v0.1.10 (2017-02-22)
* Updated MediaInfo to v0.7.93 (2017-02-28), compiled with ICL 17.0 and MSVC 12.0

[quitemice]

Because it gives a very nice "all in one" application that just works "out of the box" and doesn't depend on anything. This way LameXP can also be used as a "portable" application. The user doesn't need to bother that some temporary files get extracted on startup (and will ne cleaned-up automatically on application shutdown), as it is completely transparent to the user. Most users probably never notice.

Especially with SSD, the extraction should be extremely fast. Takes less than a second on my system! If you ever see LameXP to take more than a few seconds to startup up, get rid of the crappy A/V software that is responsible!
http://lamexp.sourceforge.net/doc/Manual.html#performance-issues

(And please don't tell me that LameXP causes your SSD to "wear out" more quickly. SSD's wearing out quickly is a common myth, maybe a problem of the very earliest SSD's, but certainly not of today's ones - as tests have shown many times)




Settings are not "not saved", but stored separately for each major release. That's because new major releases can add new settings, removed old settings, or change the meaning of existing settings.

IMO it's better to keep things separate. If you changed any of the defaults in LameXP, then you can do so again in 10 seconds. Any maybe, in the meantime, you realized that you should stick with the defaults anyway...

You can even edit the INI file and rename the INI section from "old" to "new" version, so that the "new" version will try to read your "old" settings. That's on your own risk, of course ;)




There are no plans to disable the sounds by default. You can disable them at any time though, if you don't like them.

@lord mulder

Oke thanks for your explanation!

I think your reasons are legit, and yes it's not a big deal to enter my settings again.
But i'm not sure why you save the settings separately but never use them. I mean what's the point than to save them?

but like i said it's not a real problem, and i happily continue to work with this program :D

[LoRd_MuldeR]

LameXP v4.15 Beta-3

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-alpha2 (2017-03-03) and Opus-Tools to v0.1.10 (2017-02-22)
* Updated MediaInfo to v0.7.93 (2017-02-28), compiled with ICL 17.0 and MSVC 12.0
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Some tweaks to the auto-update function in order to speed-up the update check in most situations

[LoRd_MuldeR]

LameXP v4.15 Beta-4

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Improved file name generation from meta-tags containing characters that are forbidden in file names
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-alpha2 (2017-03-03) and Opus-Tools to v0.1.10 (2017-02-22)
* Updated MediaInfo to v0.7.93 (2017-02-28), compiled with ICL 17.0 and MSVC 12.0
* Updated SoX to v14.4.2 (2015-02-22) with Dynamic Audio Normalizer v2.10 (2017-04-14) effect included
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Some tweaks to the auto-update function in order to speed-up the update check in most situations

[LoRd_MuldeR]

LameXP v4.15 Beta-5 „Ingsoc“
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2017-04-22/LameXP-BETA.2017-04-22.Release-Static.Build-1984.exe/download

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Improved file name generation from meta-tags containing characters that are forbidden in file names
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-alpha2 (2017-03-03) and Opus-Tools to v0.1.10 (2017-02-22)
* Updated MediaInfo to v0.7.94+ (2017-04-21), compiled with ICL 17.0 and MSVC 12.0
* Updated SoX to v14.4.2 (2015-02-22) with Dynamic Audio Normalizer v2.10 (2017-04-14) effect included
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Some tweaks to the auto-update function in order to speed-up the update check in most situations

http://imageshack.com/a/img924/911/ilu6ox.jpg

[Romario]

LameXP v4.15 Beta-5 „Ingsoc“
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2017-04-22/LameXP-BETA.2017-04-22.Release-Static.Build-1984.exe/download



http://imageshack.com/a/img924/911/ilu6ox.jpg

Can you please optimize your fantastic program for AMD Ryzen arhitecture ? Can you do it before final version come ? Thank you.

Is there any audio codec, at the moment, being optimized for Ryzen ?

As ilustration, look at this image in my attachment, please

[mariush]

Lame MP3 is pretty much single threaded, it will pretty much use one cpu core to encode one audio file. If you want to use all the cores in your processor, you'd have to use an application like foobar2k or LameXP to encode multiple audio files at the same time. The standard FLAC is also kinda poor at multithreading, same goes for neroAAC AAC encoder (which i still use even though apparently there's some other software supposedly better).

You can speed up encodings by running multiple conversions in parallel (up to 16-20 of them on Ryzen would be fine I guess).

You've made several posts about optimizing things for Ryzen. Ryzen architecture doesn't really have some magic instructions that would hugely affect the performance, if some application is already optimized to use the existing instructions sets from other processors like Intel Skylake, they'll work well on Ryzen as well.

x264 for example will use as many cores and threads as it feels needed, so if you're doing some high resolution high fps encoding, it will use all those 12-16 threads very well.

* for mp3, there were some attempts at making a multithreaded lame mp3, but it still works by encoding multiple audio files in parallel internally, not just one audio file... see fcMP3Enc https://hydrogenaud.io/index.php/topic,73790.0.html

* For FLAC, if you want speed you could look into CueTools.FLACCL which can use your video card to speed up encoding of audio files using OpenCL (which works on AMD and nVidia cards)

and a bit unrelated, but you asked on the x264 thread... i'm not an expert so I'm not sure... but I don't think x264 would benefit from those AVX instructions.

[Romario]

Ok, thanks for answer. I respect your opinion.

But something must be changed, lame have not been developed, actively, for three or four years now.

But please look my image in attachment. Can you explain why is 7700k so much faster than 8-core 1800x? I can't explain that, it shows how much is LAME unoptimized...

Gesendet von meinem GT-I9295 mit Tapatalk

[lvqcl]

But please look my image in attachment.

"Attachments Pending Approval" is all I can see

[mariush]

I can't view the attachment because attachments have to be reviewed by moderators and approved before people can see them. Use websites like imgur.com to upload pictures if you feel like to.

But to answer your question:

Intel 7700k has a default frequency of 4.2 Ghz and boosts up to 4.5 Ghz if only a few of the four cores are used.
AMD 1800x has a default frequency of 3.6 Ghz and boosts up to 4 Ghz if only a few of the eight cores are used.

As LAME mp3 encoder only uses older instructions sets (mmx, sse) which are pretty much same speed on both architectures, we can concentrate just on the frequency of the processors.
Since the encoder is mostly single threaded, we can assume only one core or at most two cores will have some usage, so the Intel 7700k will run those cores at 4.5 Ghz and the Ryzen 1800x will run those cores at 4 Ghz. So naturally, if 7700k is considered the default speed (100%) , then ryzen 1800x should have about 89% the performance of the Intel cpu:

4.5 ghz ... 100%
4 ghz ... ? %

? % = 4 x 100 / 4.5 = 88.%

Naturally, there are minute (very small) differences in the execution speed of those assembly instructions and there may be some differentiators between systems that affect the speed very little (like ddr4 ram frequency for example)

The point is you would see the performance difference if you encode multiple audio tracks at the same time, so that all cores would be used.
Rip an audio CD to uncompress WAV files using Exact Audio Copy and optionally (if you don't have a SSD) create a RAM Disk using software like ImDisk Ramdisk (freeware) (https://sourceforge.net/projects/imdisk-toolkit/) ... you don't want the mechanical drive affect the encoding speed when you read 10-20 audio files from the hard drive at the same time.

With a 7700k processor, since it has 4 cores and 8 threads, you can realistically encode around 10-12 audio files at the same time, before individual encoders would begin to wait for processor time. Let's go with 10.
On the 1800x processor, since it has 8 cores and 16 threads, we could realistically go with around 20 simultaneous encodings at the same time.
Both processors will have all cores used at the same time, so they won't boost (often) to their maximum frequencies, so let's assume the Intel cpu would run at 4.2 Ghz and the AMD cpu would run at 3.6 Ghz.

No you have

10 x 4.2 ghz ---- 100 %
20 x 3.6 ghz ----- ? %

? % = 20 x 3.6 x 100 % / ( 10 x 4.2) = 2 x 3.6 x 100 / 4.2 = 171.42%

So as long as you'll keep all the cores on the Ryzen 1800x busy encoding up to 20 individual audio tracks at the same time, you may get almost 1.5x-2x the performance compared to the 7700k

Of course, these are just assumptions, you'd have to test it yourself if you have access to two such systems.

[Romario]

"Attachments Pending Approval" is all I can see
Well I see my attachment without any problem. Strange...


Edit: https://ibb.co/c87xT5 ( this is my attacment )

[Atak_Snajpera]

You expect to much from Zen in single threaded applications. IPC is not that great in single thread! ALU table clearly shows that Zen loves when you throw multiple tasks on execution units.
So Ryzen optimization is simple. Keep all cores busy at all time!
https://i.imgsafe.org/6da60ecb0f.png

[Romario]

How can I use optimised lame 3.99.5 builds? While LameXP doesn't allow to change which lame build I use.

Sent from my LG-P880

[manolito]

It is still possible to use custom builds of the LameXP built-in tools (even if the manual does not mention it).

From the older LameXP FAQ:
Is there a way to use custom tools (binaries) with LameXP instead of the "built-in" ones?

LameXP uses a number third-party tools. All of these tools are already "built-in" (with a few exceptions) and
thus it is NOT required to provide separate binaries. Usually it will NOT be necessary to replace any of
the "built-in" tools with a custom (user-provided) binary. If, however, you need to replace/update/downgrade
one of the binaries for a good reason, the recommended method is re-building LameXP from the sources. If you
don't know how to build LameXP from the sources, then you probably shouldn't be trying to replace the binary.

Having said that, there now is a more convenient method for using a custom tool version (binary) instead of
the "built-in" one. This method works WITHOUT re-building LameXP. However note that the following is intended
for testing and debugging purposes only! Also note that LameXP was specifically designed to work with the
"built-in" versions of the tools. It may not work properly or may not work at all with custom tool versions!

In order to replace a "built-in" binary, simply put the user-provided binary to the following location:
<install_folder>\tools\<build_number>\<tool_name>.exe
If, for example, you want to replace 'lame.exe' in Build #666 of LameXP, you would put it to the this path:
C:\Path to your LameXP install folder\tools\666\lame.exe
(It is intended that the '<build_number>' part of the path has to be adjusted with every update of LameXP)


Cheers
manolito

[LoRd_MuldeR]

Can you please optimize your fantastic program for AMD Ryzen arhitecture ? Can you do it before final version come ? Thank you.

Is there any audio codec, at the moment, being optimized for Ryzen ?

As ilustration, look at this image in my attachment, please

Development of LAME is pretty much dead. So don't expect any optimizations for "new" processors any time soon ;)

Having said that, there is no "magic" optimization that would make LAME run a lot faster on Zen architecture all of a sudden! Yes, LAME could probably benefit from using "modern" instruction set extensions, such as AVX or AVX2 – at the moment the assembler code in LAME only uses the SSE and SSE2 extensions – but this "problem" is not specific to the Zen architecture at all. TTBOMK, the Zen architecture did not even introduce a new instruction set extension.

The reason why Ryzen 1800X performs relatively "bad" with LAME mp3 encoder is because LAME – just like most audio encoders – is completely single-threaded. And, given the current state of LAME development, I doubt this is ever going to change. Furthermore, it is well known that single-core performance still is the "weak spot" of the Zen architecture (compared to Intel Core i7 processors), even though things have been improved quite a lot since Bulldozer architecture.

As others have pointed out: You will need to run many LAME instances in parallel to take full advantage of a Ryzen processor with 16 logic cores – which is exactly what LameXP does :)


Well I see my attachment without any problem. Strange...

Attachments need to be approved by a mod, before other users can see/access them. I wasn't close to a computer in the last couple of days, so I couldn't approve it until now.


How can I use optimised lame 3.99.5 builds? While LameXP doesn't allow to change which lame build I use.

You can make LameXP use a custom build of LAME by putting your custom binary at the proper place, just like it is described in the F.A.Q. article that manolito quoted (https://forum.doom9.org/showpost.php?p=1806010&postcount=1446) (not ported to new manual yet).

Don't expect any wonders, though! LameXP already ships with up-to-date binaries of LAME 3.100 Alpha – including 64-Bit build with AVX compiler-optimizations enabled. The "best" build is automatically selected, based on the CPU's capabilities.

Note: Those compiler optimizations have a lesser effect on performance. That's because all the "hot" functions, where the vast majority of the CPU time is spent, already are written as hand-optimized assembler code...

[Romario]

How you optimised these LAME builds ? With ICL15 or newest MSCS 2017 ?

While ICL work always much better on Intel processors.

[LoRd_MuldeR]

How you optimised these LAME builds ? With ICL15 or newest MSCS 2017 ?

While ICL work always much better on Intel processors.

ICL, whatever version was up-to-date when I last built LAME.

Note that ICL has an option to add an "optimized" code path (for all compatible processors, including AMD) and a separate option to "optimize" specifically for Intel processors (potentially breaking the binary for Non-Intel processors).

I always use the former ;)

But, as said before, those compiler optimizations have a lesser effect! All the "hot" code, where ~99% of the CPU time is spent, is hand-optimized assembler code that will not be effected by compiler optimizations at all.

[Romario]

ICL, whatever version was up-to-date when I last built LAME.

Note that ICL has an option to add an "optimized" code path (for all compatible processors, including AMD) and a separate option to "optimize" specifically for Intel processors (potentially breaking the binary for Non-Intel processors).

I always use the former ;)

But, as said before, those compiler optimizations have a lesser effect! All the "hot" code, where ~99% of the CPU time is spent, is hand-optimized assembler code that will not be effected by compiler optimizations at all.

Very good, thanks.

And what about other audio encoders ? What is the situation ? Is there any actively development for OGG, or AAC codecs, with plan for future optimisations ? Can you, please, give me most optimised binarys ?

[LoRd_MuldeR]

Again: Most audio encoders already contain hand-optimized assembler code for the "hot" functions, i.e. the functions where like ~99% of the work is done.

If a particular audio encoder contains optimized assembler code for your CPU, then the encoder will automatically enable/use the optimized assembler code on your system – that is regardless of what compiler or compiler settings were used to compile the plain C/C++ code. If, on the other hand, a particular audio encoder does not contain optimized assembler code for your CPU, then there is nothing I could do about that. You'd have to ask the developer of the particular encoder ;)

All that I can do is change the compiler settings that are used to compile the plain C/C++ code. But, as pointed out several times, this has a lesser effect on the overall performance, compared to the assembler stuff...

(That plus: I already create "generic", "sse2" and "avx" builds of the encoders and LameXP will invoke the appropriate one on each system)

[mariush]

Dude, people told you already in several threads, there's very little optimizations to be done when it comes to audio... and whatever optimizations are already in such programs, they work pretty much the same on Intel and AMD processors.

Whatever "improvements" you would do on audio encoders, it would only increase the speed by a few percentages at best, and nobody cares to invest a huge amount of time for so little benefit .
If you encode the audio track of a 2 hour movie in 10x real time speed (so basically finishing compression in 10 minutes), nobody cares to optimize some software to finish the job in 9 minutes and 30 seconds.

Nobody cares about OGG anymore, it's as good as "deprecated". It's replaced by Opus which is free and open source and produces better quality than MP3 or AAC at majority - if not all - of audio bitrates .
AAC is still worth using because it's used in DVDs and has good compatibility it's often used by Youtube and Apple for streaming audio. Whatever improvements you'd get between different codec versions would probably be psycho-achoustics (as in how to modify the sound to throw out some data for better compression, while tricking your ears into thinking it sounds good)

AC3 is old enough to have its patents expired so you don't have to pay licenses for it, MP3 also expired recently if I'm not mistaken, but the quality of AC3 is not better than MP3... not worth wasting time improving encoding speeds when there's something else better.

If you want something fast and best quality for a music collection, just use FLAC for archival and Opus for listening daily. Use a player like foobar2k and you'll be fine. And if you have a music player, try and see if Rockbox supports your player: https://www.rockbox.org/

If you need speed at compressing FLAC, encode multiple tracks at same time, or use Cuetools.FLAC encoder that can use OpenCL and your video card to compress audio super fast.

Forget about MP3.

[quitemice]

It is been said that you would consider a native Linux version but this is been a while back.

So the simple question is are you still thinking about this?

I don't have the knowledge to do it myself or help you with that though.

I recently switched to Linux and thought it would be very nice :D

I know, i can use wine to run it

[LoRd_MuldeR]

It is been said that you would consider a native Linux version but this is been a while back.

So the simple question is are you still thinking about this?

I don't have the knowledge to do it myself or help you with that though.

I recently switched to Linux and thought it would be very nice :D

I know, i can use wine to run it

It is still possible, because LameXP is written in C++ and based on the Qt cross-platform framework. However, it is unlikely to happen anytime soon, because:
I have a full-time job
Currently, LameXP is compiled with Visual C++ compiler. On Linux we'd have to compile it with GCC or LLVM. While, in theory, all C++ compilers should be "compatible", because they implement the same standard, in reality there always are some differences between compilers that will break your code. So, code that was developed and tested on Visual C++ will certainly require various fixes/workarounds to compile with GCC or LLVM.
Currently, LameXP is built with MSBuild (Visual Studio), which is not an option for Linux. So, in order to build LameXP on Linux we'd have write Makefiles first. Or we'd have to use something like CMake.
While LameXP is based on the Qt framework and most of the code should be perfectly cross-platform, there is also quite some Windows-specific code that uses the Win32 API. Of course, I keep that Windows-specific code separate from the rest, mostly encapsulated in the MUtils library. Still, for any Windows-specific function I'd either have to write a Linux equivalent or find a workaround to get a long without that function.
Currently, all encoders and decoders are included in LameXP as pre-compiled binaries. On Windows, this is necessary, because Windows doesn't ship with the required audio encoders/decoders or a way to get them easily. Also most Windows users don't have a clue how to compile stuff by themselves. But, on Linux, providing pre-compiled binaries is not feasible. Linux binaries generally work only on the same distribution where they have been compiled. So, instead, we'd have to install the required encoder and decoder binaries from the individual distribution's repository. Or have the user compile them. In any case, a lot of things need to change in how encoder/decoder binaries are invoked.

[LoRd_MuldeR]

LameXP v4.15 Beta-8

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Improved file name generation from meta-tags containing characters that are forbidden in file names
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-alpha2 (2017-05-05) and Opus-Tools to v0.1.10 (2017-02-22)
* Updated MediaInfo to v0.7.95 (2017-05-04), compiled with ICL 17.0 and MSVC 12.0
* Updated SoX to v14.4.2 (2015-02-22) with Dynamic Audio Normalizer v2.10 (2017-04-14) effect included
* Updated mpg123 decoder to v1.24.0 (2017-03-02), compiled with GCC 6.3.0
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Updated Monkey's Audio binary to v4.25 (2017-03-12), compiled with ICL 17.0 and MSVC 14.0
* Some tweaks to the auto-update function in order to speed-up the update check in most situations

[LoRd_MuldeR]

LameXP v4.15 RC-1

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Improved file name generation from meta-tags containing characters that are forbidden in file names
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-alpha2 (2017-05-05) and Opus-Tools to v0.1.10 (2017-02-22)
* Updated MediaInfo to v0.7.95 (2017-05-04), compiled with ICL 17.0 and MSVC 12.0
* Updated SoX to v14.4.2 (2015-02-22) with Dynamic Audio Normalizer v2.10 (2017-04-14) effect included
* Updated mpg123 decoder to v1.24.0 (2017-03-02), compiled with GCC 6.3.0
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Updated Monkey's Audio binary to v4.25 (2017-03-12), compiled with ICL 17.0 and MSVC 14.0
* Some tweaks to the auto-update function in order to speed-up the update check in most situations

[LoRd_MuldeR]

LameXP v4.15 RC-2

Changes between v4.14 and v4.15 [*unreleased*]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Improved file name generation from meta-tags containing characters that are forbidden in file names
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-beta (2017-05-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.95 (2017-05-04), compiled with ICL 17.0 and MSVC 12.0
* Updated SoX to v14.4.2 (2015-02-22) with Dynamic Audio Normalizer v2.10 (2017-04-14) effect included
* Updated mpg123 decoder to v1.24.0 (2017-03-02), compiled with GCC 6.3.0
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Updated Monkey's Audio binary to v4.25 (2017-03-12), compiled with ICL 17.0 and MSVC 14.0
* Some tweaks to the auto-update function in order to speed-up the update check in most situations

[LoRd_MuldeR]

LameXP v4.15 Final
https://github.com/lordmulder/LameXP/releases/latest

Changes between v4.14 and v4.15 [2017-05-31]:
* Fixed a bug in auto-rename feature, that caused problems when a meta-tag contained path separators
* Fixed included MediaInfo binary not working on processor without SSE2 support
* Improved file name generation from meta-tags containing characters that are forbidden in file names
* Some improvements for "high DPI" screens: Adjust initial window size according to DPI setting
* Updated Opus encoder/decoder libraries to v1.2-beta (2017-05-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.95 (2017-05-04), compiled with ICL 17.0 and MSVC 12.0
* Updated SoX to v14.4.2 (2015-02-22) with Dynamic Audio Normalizer v2.10 (2017-04-14) effect included
* Updated mpg123 decoder to v1.24.0 (2017-03-02), compiled with GCC 6.3.0
* Updated FAAD decoder to v2.7 from CVS in order to include latest libFAAD fixes (2016-11-11)
* Updated Monkey's Audio binary to v4.25 (2017-03-12), compiled with ICL 17.0 and MSVC 14.0
* Some tweaks to the auto-update function in order to speed-up the update check in most situations
* Updated language files (big thank-you to all contributors !!!)

[LoRd_MuldeR]

LameXP v4.16 Alpha-3

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-2
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.98 (2017-08-08), compiled with ICL 17.0 and MSVC 12.0
* Some improvements to output file name generation code

[cindernat]

First of all, great program - thank you so much.

One issue I'm having is when I am doing a batch conversion, for any folder that has files in its root directory plus additional folders, the additional folders are ignored.

EG: Within Artist A's folder, I have 3 albums and 4 single tracks (single tracks existing in that artist's root directory). In this scenario, only the single tracks are converted and the 3 album folders are skipped.

Yet Artist B, who only has album folders within their folder and no single tracks, nothing is skipped and all converted.

I hope that makes sense.

Anyone else had this occur?

[LoRd_MuldeR]

First of all, great program - thank you so much.

One issue I'm having is when I am doing a batch conversion, for any folder that has files in its root directory plus additional folders, the additional folders are ignored.

EG: Within Artist A's folder, I have 3 albums and 4 single tracks (single tracks existing in that artist's root directory). In this scenario, only the single tracks are converted and the 3 album folders are skipped.

Yet Artist B, who only has album folders within their folder and no single tracks, nothing is skipped and all converted.

I hope that makes sense.

Anyone else had this occur?

You mean this happens when you are adding a directory to the "Source Files" tab via Drag'n'Drop?

The reason is that, in this case, only the files in the directory itself are added. We do not, by default, add the whole directory tree recursively, because it could easily take ages on a massive directory tree. The only case when it will descend into sub-directories automatically is when the "starting" directory did not contain any files at all. And even then, it only descends to the next level, until some file have been found.

If you which to add a whole directory tree, in a fully recursive manner, you can do so via "File" -> "Open Folder Recursively".

[cindernat]

You mean this happens when you are adding a directory to the "Source Files" tab via Drag'n'Drop?

The reason is that, in this case, only the files in the directory itself are added. We do not, by default, add the whole directory tree recursively, because it could easily take ages on a massive directory tree. The only case when it will descend into sub-directories automatically is when the "starting" directory did not contain any files at all. And even then, it only descends to the next level, until some file have been found.

If you which to add a whole directory tree, in a fully recursive manner, you can do so via "File" -> "Open Folder Recursively".

Yep - that'd be it then. Didn't realise! Will take note for next time. Thank you!

[LoRd_MuldeR]

LameXP v4.16 Alpha-4

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-3
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.98 (2017-08-08), compiled with ICL 17.0 and MSVC 12.0
* Some improvements to output file name generation code

[dissory]

Thanks for the great program, LoRd_MuldeR!

One thing I noticed though is if I convert .wav files containing metadata to .flac and back again to .wav all the original .wav metadata such as "Track name" is lost. Any way to fix this?

[LoRd_MuldeR]

Thanks for the great program, LoRd_MuldeR!

One thing I noticed though is if I convert .wav files containing metadata to .flac and back again to .wav all the original .wav metadata such as "Track name" is lost. Any way to fix this?

Hello.

The procedure is as follows: We use MediaInfo to detect the meta tags from the original input file, then we decompress the input file to WAV, and finally we encode to temporary WAV using the selected encoder (e.g. LAME, VorbisEnc, OpusEnc, or FLAC). Also, when we invoke the selected encoder, we forward the previously detected meta tags - as far as possible. The capabilities of the different encoders supported by LameXP differ greatly in what meta tags they support. But most of them support at least the bear minimum. Now, the "problem" with the WAV format is that WAV format does not really use an encoder at all! WAV format is the uncompressed output of the decoder. If, for example, you "convert" from FLAC to WAV, the resulting WAV file is actually the direct output of the FLAC decoder! There is no "encoding" step, in which we could embed the meta tags. And, apparently, the FLAC decoder does not add meta tags to the WAV file it produces.

BTW: I'm not even sure there is a standardized way of storing meta tags in WAV files. Sure, the WAV format is based on the RIFF format, so you can add arbitrary additional RIFF chunks to the file and any well-behaving application should simply ignore those additional RIFF chunks, if it doesn't understand them. But unless there is a widely-support standard for embedding meta tags in WAV format, it will be pretty pointless endeavor...

[RieGo]

hello,
just wondering: why is multithreading limited to 10 threads? :)
is it on purpose. is there a setting somewhere?
edit: nevermind. i just found the setting. seems like autodetection is not working properly. setting it manually fixes it

[LoRd_MuldeR]

hello,
just wondering: why is multithreading limited to 10 threads? :)
is it on purpose. is there a setting somewhere?
edit: nevermind. i just found the setting. seems like autodetection is not working properly. setting it manually fixes it

"Auto-detection" is working as expected, probably. That is because auto-detection has not been implemented to simply run as many encoder instances in parallel as there are (logical) CPU cores available. Instead, it has been optimized to run as many encoder instances in parallel as give the maximum throughput (or, equivalently, minimize overall encoding time). Note that running too many instances in parallel can easily result in HDD thrashing and thus slow things down considerably, as all those parallel instances also need to read their respective source file and write their respective output file. The following "cores to instances" curve has been derived experimentally, with the help of various LameXP users:

https://i.imgur.com/6XYwr03.png

[RieGo]

"Auto-detection" is working as expected, probably. That is because auto-detection has not been implemented to simply run as many encoder instances in parallel as there are (logical) CPU cores available. Instead, it has been optimized to run as many encoder instances in parallel as give the maximum throughput (or, equivalently, minimize overall encoding time). Note that running too many instances in parallel can easily result in HDD thrashing and thus slow things down considerably, as all those parallel instances also need to read their respective source file and write their respective output file. The following "cores to instances" curve has been derived experimentally, with the help of various LameXP users:

https://i.imgur.com/6XYwr03.png

wow. that's interesting. thanks for clearing up.
in my case it was faster using more threads manually, but that doesn't mean it's the same for everybody. probably depends on a lot of components.

[mariush]

That may have to revisited, or may need to use a number of threads if the input and outputs are on mechanical drives, and another number for SSDs , RAMDisks, NAS etc.

[LoRd_MuldeR]

In fact, we should probably use a simple "1:1" mapping, when a SSD (solid-state drive) is detected. But it turns out to be surprisingly difficult to tell SSD's and "normal" HDD's apart on windows ;)

Here is an attempt (simple command-line application for now), maybe you can give it a try:
https://sourceforge.net/projects/muldersoft/files/SSDD/SSDD.2017-10-08.zip/download

[mariush]

Yeah, it works fine for me.
First thought that came to mind was running a simple test like reading some 10K random 512 bytes sector reads from the hard drive, as such a big quantity of sectors and so spread out would be unlikely to be cached by the OS. Mechanical drives (even hdd with some nand cache) would have high seek times, while SSDs and ram drives would be fast. NAS drives may be somewhere in between, due to tcp/ip and all that.

[RieGo]

In fact, we should probably use a simple "1:1" mapping, when a SSD (solid-state drive) is detected. But it turns out to be surprisingly difficult to tell SSD's and "normal" HDD's apart on windows ;)

Here is an attempt (simple command-line application for now), maybe you can give it a try:
https://sourceforge.net/projects/muldersoft/files/SSDD/SSDD.2017-10-08.zip/download

my 2 ssds are correctly detected, but the encrypted volume that's on an ssd isn't detected at all (maybe because it's mounted as removable storage?)
but still that's a good starting point

[LoRd_MuldeR]

my 2 ssds are correctly detected, but the encrypted volume that's on an ssd isn't detected at all (maybe because it's mounted as removable storage?)

Not much of a surprise. What we can do is mapping a logical drive (i.e. drive letter) to the underlying physical device or devices – multiple logical drives may map to the same physical device, and a logical drive may span multiple physical devices. Then we can query certain properties of those physical device(s) which allow us to "detected" an SSD or SSD-like drive. However, if some software creates a "virtual" drive, it is pretty much impossible to tell on which physical drive or drives the data is actually stored. It may emulate (and thus look like) a "fixed" disk, but we don't know whether the contents of "virtual" drive are stored on a (local) physical device at all – might be a "RAM" disk, or a "cloud" drive, or whatsoever...

[LoRd_MuldeR]

LameXP v4.16 Alpha-5

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-4
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.98 (2017-08-08), compiled with ICL 17.0 and MSVC 12.0
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Improved auto-detection of max. parallel instances on computers with SSD (or similar) drive
* Some improvements to output file name generation code

[Motenai Yoda]

It's me or when there is a beta update it can't be avoided?

[LoRd_MuldeR]

It's me or when there is a beta update it can't be avoided?

See information included with pre-release ("beta") builds:

LameXP Pre-Release Version
--------------------------

This pre-release version of LameXP is intended for testing and evaluation only.
We recommend to *not* use this version for production. Use it at your own risk!

Note: This "test" version of LameXP will expire 30 days after the release date.
LameXP is free/libre software. The "stable" versions of LameXP do *not* expire!

So yeah, if you want to support development of LameXP by testing out pre-release ("beta") builds, then you'll need to update to the latest build about every ~30 days.

There is nothing, though, that would urge you to upgrade from the latest "stable" version to any "beta" version...

[LoRd_MuldeR]

LameXP v4.16 Alpha-6

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-4
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.7 (2017-09-25), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.98 (2017-08-08), compiled with ICL 17.0 and MSVC 12.0
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Improved auto-detection of max. parallel instances on computers with SSD (or similar) drive
* Some improvements to output file name generation code

[LoRd_MuldeR]

LameXP v4.16 Alpha-7

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-4
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.7 (2017-09-25), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v0.7.98 (2017-08-08), compiled with ICL 17.0 and MSVC 12.0
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Improved auto-detection of max. parallel instances on computers with SSD (or similar) drive
* Some improvements to output file name generation code

This should fix a compatibility issue in "mpg123" introduces in previous build...

[LoRd_MuldeR]

LameXP v4.16 Alpha-9

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-4
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.7 (2017-09-25), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v17.10 (2017-11-02), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with SSD (or similar) drive
* Some improvements to output file name generation code

[danlock]

First, obligatory (IMO) appreciation as part of my first post: I love LameXP and have used it for years! :)

Now, my report (the primary message): When converting from any MP3-format file, LameXP stops before decoding the MP3 with an error similar to this:


LameXP v4.16 (Build #2056), compiled on 2017-11-25 at 16:05:01

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

The format of this file is NOT supported:
E:/<directory>/<filename>.mp3

Container Format: MPEG Audio
Audio Format: Type: MPEG Audio, Profile: Layer 3, Version: 1, Bitrate: ≈64 kbps (Variable)

128 kbps (constant) and 320 kbps (constant) files from other sources abort with the same error (indicating the relevant format in the error text).


The CMD console window open at the time of the error contains the following text at the bottom of the output:


Initializing encoding process...
DiskSpace observer started!
CPU observer started!
RAM observer started!
Process thread {f4d1a364-f902-481d-a14a-5f7e2b2ab27b} has started.
Running jobs: 0



This has occurred only for the past 2-3 alpha versions of LameXP.

As far as I can remember, the first version which used the "new" version of LAME did not abort MP3 decoding with that error, but more-recent versions of LameXP have presented that error upon MP3 decode. (edit: I'm not completely certain about that)

Thanks for reading! :)

[manolito]

Hi danlock,

interesting report...
I am quite sure that it's not Lame.exe which is to blame, but that it is something about the latest Alpha versions of LXP which causes the issue.

I still use the current stable version 4.15, and because I never liked LoRd_MuldeR's approach to use Alpha versions of some helper tools even in stable LXP versions I regularly replace these tools with stable versions. In this case it was Lame v. 3.100 Alpha which I replaced with v. 3.95 stable.

After your post I updated Lame for LXP with the current stable version 3.100 (I used the RareWares download), and it works flawlessly for decoding and encoding. No problems whatsoever, and for me this means that the fault you are experiencing is caused not by Lame.exe, but by the current LXP Alpha.


Cheers
manolito

[danlock]

Right... the stable build has the older version of LAME and older versions of Opus and opusenc.

I want the newer Opus very much [from the unreleased builds] because it is a large upgrade in terms of audio quality when encoding certain files and fixes some bugs.

The unreleased alpha/beta builds contain, as far as LAME goes, an update to "LAME encoder v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1" ...

I'm wondering if I lack a support file to run files compiled "with ICL 18.0 and MSVC 14.1". I'll check for a Microsoft runtime for MSVC 14.1 and see if my up-to-date system already has it installed. I'll have to search for ICL because I'm not sure what that acronym stands for. I'm too tired right now to verify that particular acronym, so I'll check it later... or it might pop into my head when I'm more alert.

Thanks for the reply! I know rolling back to the most recent stable build is an option, but that would mean using libopus 1.x rather than the newest 2.1.1 [virtually identical to 2.1] for encoding, and 1.1.x and 2.x behave surprisingly differently when encoding audio.

You can check opus-codec.org or the Opus RFC's (https://tools.ietf.org/html/rfc6716) most recent update (https://tools.ietf.org/html/rfc8251) at ietf.org as well as the Opus thread on hydrogenaud.io for a more precise Opus changelog... but I digress.

I'm eager to read LoRd MuldeR's response... does LAME 3.100 Final support every variation of MP3-encoded file? It says Final so it should, right? Did any of the CLI options change that haven't yet been fixed in LameXP's code, or does its method of invocation/hooking differ in some way from the earlier versions of LAME and/or mpg123 which worked correctly? [This version might work correctly as well, depending on a few things on my end.]

I still suspect it might be a missing dependency on my system rather than anything LM did. I keep forgetting to check for and validate certain things that might be responsible.... hmm. :o

[manolito]

I assume that you are familiar with the LXP method to replace built-in tools with different versions...
https://forum.doom9.org/showthread.php?p=1806010#post1806010

Using this method it should be easy to replace the built-in Opus files (opusdec.exe and opusenc.exe) with newer ones. Of course only as long as the user interface has not changed.

As for your concerns about missing support files for newer executables I don't think so. ICL means "Intel Compiler" and MSVC stands for "Microsoft Visual C". LoRd_MuldeR always made sure that LXP is self-contained so it does not need any additional support libraries.


Cheers
manolito

[LoRd_MuldeR]

First, obligatory (IMO) appreciation as part of my first post: I love LameXP and have used it for years!

You are welcome!

When converting from any MP3-format file, LameXP stops before decoding the MP3 with an error similar to this:
LameXP v4.16 (Build #2056), compiled on 2017-11-25 at 16:05:01

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

The format of this file is NOT supported:
E:/<directory>/<filename>.mp3

Container Format: MPEG Audio
Audio Format: Type: MPEG Audio, Profile: Layer 3, Version: 1, Bitrate: ≈64 kbps (Variable)

128 kbps (constant) and 320 kbps (constant) files from other sources abort with the same error (indicating the relevant format in the error text).[INDENT]

Hello, is that really everything you can see in the log of the failed job?

I'm suspicious, because I can see no error there. Doesn't even look like it started doing anything :confused:

As far as I can remember, the first version which used the "new" version of LAME did not abort MP3 decoding with that error, but more-recent versions of LameXP have presented that error upon MP3 decode.

I am pretty sure that this problem is not related to the LAME encoder, or the MPG123 decoder, since from you log it doesn't look like we ever got to the point where any of those would be invoked.

Instead, I suspect that it is somehow related to the recent MediaInfo changes. I will have to look into this ASAP... (but not tonight ;))

[danlock]

Hello, is that really everything you can see in the log of the failed job?

Before that, it [the command window] shows the usual startup information and checks for the presence of the optional other licensed codec files (Nero/FHG/ALAC), then says the file was added correctly. After a line break or two, it then displays the text I quoted in my initial message (presumably text which was displayed after I tried to convert the MP3).

I'm suspicious, because I can see no error there. Doesn't even look like it started doing anything :confused:

Yeah, that's all there is, which is what confused me also.

Only MP3 files seem to be affected, and the process of decoding aborts before it starts with a LameXP error window saying the file can't be processed and indicating I can click (double-click?) the filename for more details. The window displayed after clicking the filename is where the "This file is NOT supported!" error I quoted is shown. After that, I can close that window and continue using LameXP for other things or quit or whatever.

I've tried both changing and removing tags/metadata (ID3 v1.1 and v2.x) in the problematic MP3 files LameXP has told me were not supported (despite my having used them as source files in older versions of LameXP without error before) and LameXP still reports the files as "NOT supported" and doesn't even begin the decoding process.

I think you're correct in suspecting that LAME has not yet been invoked when the file is reported as being unsupported; in my fatigue when writing the initial message, I was confusing LameXP's error window with one reporting output from LAME.

Admittedly, I've only tried converting Ogg, Opus, MP3, WAV, and FLAC files during the time this "no MP3" error has existed in the betas, so I don't know whether any other non-MP3 files abort prior to decoding (Ogg, Opus, WAV, and FLAC work correctly and as-expected).

thanks! :)

[danlock]

I assume that you are familiar with the LXP method to replace built-in tools with different versions...
https://forum.doom9.org/showthread.php?p=1806010#post1806010

Using this method it should be easy to replace the built-in Opus files (opusdec.exe and opusenc.exe) with newer ones. Of course only as long as the user interface has not changed.

I read that, but didn't think of it until now. Thanks for reminding me, manolito. :D I'll keep that in mind if I decide to use that method. (I think all the changes to Opus were internal and did not affect the interface.)

[manolito]

Instead, I suspect that it is somehow related to the recent MediaInfo changes. I will have to look into this ASAP... (but not tonight ;))

In my LameXP installation of the stable version 4.15 I have replaced the built-in MediaInfo.exe with the current version 17.10 from the Mediaarea Web page:
http://mediaarea.net/download/binary/mediainfo/17.10/MediaInfo_CLI_17.10_Windows_i386.zip

and this does not introduce any problems. If the issue is related to recent MediaInfo changes, then it looks like it must be your MediaInfo build which comes with the LXP installer.

Should be easy to confirm by danlock:
Just download MediaInfo.exe from the above link and put the executable in the appropriate folder. If the problem disappears then it does not have anything to do with MediaInfo.


Cheers
manolito

[LoRd_MuldeR]

In my LameXP installation of the stable version 4.15 I have replaced the built-in MediaInfo.exe with the current version 17.10 from the Mediaarea Web page:
http://mediaarea.net/download/binary/mediainfo/17.10/MediaInfo_CLI_17.10_Windows_i386.zip

and this does not introduce any problems. If the issue is related to recent MediaInfo changes, then it looks like it must be your MediaInfo build which comes with the LXP installer.

It is the "XML formatted" output of MediaInfo that has changed recently:

Version 17.10, 2017-11-02
--------------
[...]
+ New MediaInfo XML output, with XSD, more suitable for automatic parsing. Use Option("Inform", "OLDXML") for keeping previous behavior
[...]

...and only the latest LameXP v4.16 builds will actually request XML format from MediaInfo. Which explains why older versions are not affected.

[LoRd_MuldeR]

LameXP v4.16 Alpha-10

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-4
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.7 (2017-09-25), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.2.1 (2017-07-26) and Opus-Tools to v0.1.10 (2017-05-25)
* Updated MediaInfo to v17.10 (2017-11-02), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with SSD (or similar) drive
* Some improvements to output file name generation code

[LoRd_MuldeR]

Yeah, that's all there is, which is what confused me also.

Only MP3 files seem to be affected, and the process of decoding aborts before it starts with a LameXP error window saying the file can't be processed and indicating I can click (double-click?) the filename for more details. The window displayed after clicking the filename is where the "This file is NOT supported!" error I quoted is shown. After that, I can close that window and continue using LameXP for other things or quit or whatever.

So, the "format version" string returned by MediaInfo (in XML format) has changed slightly. This resulted in LameXP failing to select the "right" decoder class. Instead, the file was treated like an unsupported format.

Should be fixed (https://github.com/lordmulder/LameXP/commit/ec3632aa4581d8b85c078771b7893f2b182ec969) by now, hopefully ;)

[Floatingshed]

Hello LoRd_MuldeR, I have only just discovered this excellent tool. I was searching for a quick and easy way to convert 12,000 audio files to a much smaller size for streaming use. Quality is unimportant, it is to serve as a reminder of how the audio sounds (begins and ends) in a remote radio environment. Anyway I am converting to ogg with quality -2, I could cut my file sizes even further by switching to mono but that option is only available for mp3. Can I possibly override the ogg settings somehow? Thanks.

[LoRd_MuldeR]

Hello LoRd_MuldeR, I have only just discovered this excellent tool. I was searching for a quick and easy way to convert 12,000 audio files to a much smaller size for streaming use. Quality is unimportant, it is to serve as a reminder of how the audio sounds (begins and ends) in a remote radio environment. Anyway I am converting to ogg with quality -2, I could cut my file sizes even further by switching to mono but that option is only available for mp3. Can I possibly override the ogg settings somehow? Thanks.

Yes. Try adding the custom OggEnc2 option "--downmix". From OggEnc2 manpage:

--downmix Downmix stereo to mono. Only allowed on stereo
input.

[Floatingshed]

I followed the instructions precisely, created the tools/version folder structure but it doesn't appear to be using my oggenc2 at all.

[manolito]

I think you misunderstood LoRd_Mulder's instructions. To add a custom option to the Ogg encoder there is no need to create a "tools\version" folder - this is meant for using a different encoder executable.

In LameXP under "Advanced Options" near to the bottom there are fields where you can add custom options to the internal encoders. Just enter "--downmix" here for the Ogg encoder.

Good luck
manolito

[LoRd_MuldeR]

In LameXP under "Advanced Options" near to the bottom there are fields where you can add custom options to the internal encoders. Just enter "--downmix" here for the Ogg encoder.

Exactly. Also there is a small help button at that location, which will show you other "custom" options you may add.

[Floatingshed]

Oh how stupid of me, I didn't notice that the advanced options panel was scrollable. Duh!
Thanks both.

[danlock]

I didn't notice that the advanced options panel was scrollable.
@Floatingshed: In my experience, changing the bitrate and channels (mono/stereo/etc.) for MP3 files near the top of the Advanced Options tab will cause LameXP to encode Ogg files using the same options as long as the options chosen are valid for Ogg.

Using the Custom Options available for each filetype as suggested by manolito and verified by LoRd MuldeR seems like a more precise method of doing so, however.

@LoRd MuldeR: Thanks for the quick fix :) I wish all software were as easy to update as LameXP and other similarly-simple auto-updating programs! Vielen Dank!
:thanks:

[LoRd_MuldeR]

LameXP v4.16 Beta-1

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-5
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.8 (2017-12-02), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.2.1-35 (2017-11-16) and Opus-Tools to v0.1.10-9 (2017-05-25)
* Updated MediaInfo to v17.10 (2017-11-02), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code

[LoRd_MuldeR]

LameXP v4.16 Beta-2

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-5
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.8 (2017-12-02), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.2.1-35 (2017-11-16) and Opus-Tools to v0.1.10-9 (2017-05-25)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v17.10 (2017-11-02), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile

[LoRd_MuldeR]

LameXP v4.16 Beta-3

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-5
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.8 (2017-12-02), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.2.1-35 (2017-11-16) and Opus-Tools to v0.1.10-9 (2017-05-25)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v17.10 (2017-11-02), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile[/COLOR]

[LoRd_MuldeR]

LameXP v4.16 Beta-6

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017 with Update-5
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.8 (2017-12-02), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.3-beta-2 (2018-01-26) and Opus-Tools to v0.1.10-12 (2018-01-02)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v17.12 (2017-12-21), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile

[LoRd_MuldeR]

LameXP v4.16 Beta-9

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.8 (2017-12-02), compiled with GCC 7.2.0
* Updated Opus encoder/decoder libraries to v1.3-beta-15 (2018-02-22) and Opus-Tools to v0.1.10-49 (2018-02-24)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v17.12 (2017-12-21), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[ggtop]

Hi LordMulder,
I recently figured out LameXP has a cuesheet import function :D. That'll make my life a lot of easier in the future because I used other tools in the past to split WAV images...
One cosmetic thing though. The column index is dropping the hour from the timestamp (title 10). See attached screenshot from LameXP and the original cue file created by Exact Audio Copy.
BTW Would be better to display 63... min instead of 1:03:...

TRACK 09 AUDIO
TITLE "Track09"
PERFORMER "Die drei !!!"
REM COMPOSER ""
INDEX 01 57:30:36
TRACK 10 AUDIO
TITLE "Track10"
PERFORMER "Die drei !!!"
REM COMPOSER ""
INDEX 01 63:51:43

Have nice Eastern,
ggtop

[LoRd_MuldeR]

Hi LordMulder,
I recently figured out LameXP has a cuesheet import function :D. That'll make my life a lot of easier in the future because I used other tools in the past to split WAV images...
One cosmetic thing though. The column index is dropping the hour from the timestamp (title 10). See attached screenshot from LameXP and the original cue file created by Exact Audio Copy.
BTW Would be better to display 63... min instead of 1:03:...

TRACK 09 AUDIO
TITLE "Track09"
PERFORMER "Die drei !!!"
REM COMPOSER ""
INDEX 01 57:30:36
TRACK 10 AUDIO
TITLE "Track10"
PERFORMER "Die drei !!!"
REM COMPOSER ""
INDEX 01 63:51:43

Have nice Eastern,
ggtop

Okay, I see why that happens. I was using the QTime (http://doc.qt.io/archives/qt-4.8/qtime.html) class to convert the time index to a string. QTime wraps around the "minute" component to zero after 59 :eek:

Now I'm doing the conversion manually, so that the "minute" component can go up to 99. Please try with the new TEST build:
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2018-04-01/LameXP-BETA.2018-04-01.Release-Static.Build-2106.exe/download

Regards.

[ggtop]

...Please try with the new TEST build...

Many thanks for the quick fix. I can confirm it works. Also tested some other cue/wav files.

ggtop

[LoRd_MuldeR]

LameXP v4.16 RC-1

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.10 (2018-03-05), compiled with GCC 7.3.0
* Updated Opus encoder/decoder libraries to v1.3-beta-31 (2018-03-27) and Opus-Tools to v0.1.10-51 (2018-03-04)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v17.12 (2017-12-21), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[LoRd_MuldeR]

LameXP v4.16 RC-2

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.10 (2018-03-05), compiled with GCC 7.3.0
* Updated Opus encoder/decoder libraries to v1.3-beta-31 (2018-03-27) and Opus-Tools to v0.1.10-51 (2018-03-04)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v17.12 (2017-12-21), compiled with ICL 18.0 and MSVC 14.1
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[Kisa_AG]

LameXP v4.16 RC-2
...
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
...

Hello!
Why don't you update QAAC to the newesr 2.66? Anything wrong with it?

[LoRd_MuldeR]

Hello!
Why don't you update QAAC to the newesr 2.66? Anything wrong with it?

The changelog for v4.16 is the accumulation of everything that happened in the past ~1 year since the previous release.

QAAC v2.64 simply was the latest version of QAAC at the time when I last updated QAAC.

I usually try to keep all tools up-to-date, but I also have a real-life job, so I can't update everything all the time ;)

(Also, don't expect any "spectacular" improvements in the new QAAC version. After all, it is "only" front-end to Apple's AAC encoder)

[LoRd_MuldeR]

LameXP v4.16 RC-3

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.10 (2018-03-05), compiled with GCC 7.3.0
* Updated Opus encoder/decoder libraries to v1.3-beta-31 (2018-03-27) and Opus-Tools to v0.1.10-51 (2018-03-04)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v18.03.1 (2018-03-26), compiled with ICL 18.2 and MSVC 15.6
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[johnsonlam]

The changelog for v4.16 is the accumulation of everything that happened in the past ~1 year since the previous release.

QAAC v2.64 simply was the latest version of QAAC at the time when I last updated QAAC.

I usually try to keep all tools up-to-date, but I also have a real-life job, so I can't update everything all the time ;)

(Also, don't expect any "spectacular" improvements in the new QAAC version. After all, it is "only" front-end to Apple's AAC encoder)

Thanks for your work, I've enjoy LameXP and other utilities for almost a decade, some people did have most of their real-life besides the monitor, never mind.
I've noticed both the Doom9 and HydrogenAudio was not as crowd as before.

[LoRd_MuldeR]

LameXP v4.16 RC-4

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.10 (2018-03-05), compiled with GCC 7.3.0
* Updated Opus encoder/decoder libraries to v1.3-beta-31 (2018-03-27) and Opus-Tools to v0.1.10-51 (2018-03-04)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v18.03.1 (2018-03-26), compiled with ICL 18.2 and MSVC 15.6
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[boyumeow]

Sorry to bother U again, but I just encounter the not able to encode Chinese character named song again, just wonder was this fixed before cause I somehow remember U did it?

LameXP v4.16 (Build #2124), compiled on 2018-04-17 at 20:19:48

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

C:/Users/AhBoy/AppData/Local/Temp/e507d1c81c1faf6c/lxp_oggdec.exe -w C:\Users\AhBoy\AppData\Local\Temp\e507d1c81c1faf6c\07d05cd64630cc93.wav "E:\Animovies\And to be remux\天下有情人.ogg"

OggDec v1.10.1 (libVorbis 1.3.5) Compiled on: Mar 19 2015
ERROR: cannot open E:\Animovies\And to be remux\?????.ogg
********** Done decoding all input files. **********

Exited with code: 0x0000

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

C:/Users/AhBoy/AppData/Local/Temp/e507d1c81c1faf6c/lxp_sox.exe --i C:\Users\AhBoy\AppData\Local\Temp\e507d1c81c1faf6c\07d05cd64630cc93.wav

C:\Users\AhBoy\AppData\Local\Temp\e507d1c81c1faf6c\lxp_sox.exe FAIL formats: can't open input file `C:\Users\AhBoy\AppData\Local\Temp\e507d1c81c1faf6c\07d05cd64630cc93.wav': WAVE: RIFF header not found

Exited with code: 0x0001

It encode successfully if I rename it to English character. I'm using Win10x64 for your info.

Thanks and have a nice everyday.

[LoRd_MuldeR]

Sorry to bother U again, but I just encounter the not able to encode Chinese character named song again, just wonder was this fixed before cause I somehow remember U did it?

It encode successfully if I rename it to English character. I'm using Win10x64 for your info.

Thanks and have a nice everyday.

According to your log, the file name was passed correctly to OggDec by LameXP, however OggDec failed to open the file.

It appears that OggDec does not support Unicode file names :o

Maybe I will try to build OggDec from the sources myself and patch in Unicode support...

[LoRd_MuldeR]

LameXP v4.16 RC-6

Changes between v4.15 and v4.16 [*unreleased*]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.10 (2018-03-05), compiled with GCC 7.3.0
* Updated Opus encoder/decoder libraries to v1.3-beta-31 (2018-03-27) and Opus-Tools to v0.1.10-51 (2018-03-04)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated Vorbis decoder to OggDec v1.10.1+ (2015-03-19), using libVorbis v1.3.6 (2018-03-16)
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v18.03.1+ (2018-04-19), compiled with ICL 18.2 and MSVC 15.6
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[boyumeow]

Hi LM, thanks for your kind attention and quick fix, this static build 2130 works for the Unicode support, hope I didn't create new bugs to LameXP.
Didn't realize OggDec does not support Unicode file names, I only just found it a few days ago when I want to share the happiness with a friend, not sure her phone support playing ogg files, so thinking encode into mp3.
Anyway, thanks and have a nice everyday :).

[foxyshadis]

Do you have the Oggdec patch? Sounds like it'd be useful to polish up and submit to xiph. Fortunately Opus doesn't seem to have that problem.

[LoRd_MuldeR]

Do you have the Oggdec patch? Sounds like it'd be useful to polish up and submit to xiph. Fortunately Opus doesn't seem to have that problem.

Opus-Tools doesn't have the problem (anymore), as my Unicode patch was already adopted (http://git.xiph.org/?p=opus-tools.git;a=commit;h=58347273ab4c9e9d30ab8ffd62acbac348f7e0c8). The patch for OggDec (John Edwards' version) is provided here (https://github.com/lordmulder/LameXP/blob/master/etc/Patches/OggDec-v1.10.1-Win32-UnicodeSupport%2BFlushFix.diff). Also submitted to the author.

[Gravitator]

Привет.
The program instead of the directory "Z:" selects the directory in which the LameXP program is installed "Z:\LameXP".
> DEMO (https://files.videohelp.com/u/227452/LameXP-RC6.2018-04-20.Release-Static.Build-2130%20%281%29.mkv)

[LoRd_MuldeR]

Привет.
The program instead of the directory "Z:" selects the directory in which the LameXP program is installed "Z:\LameXP".
> DEMO (https://files.videohelp.com/u/227452/LameXP-RC6.2018-04-20.Release-Static.Build-2130%20%281%29.mkv)

Seems strange :confused:

Would you kindly try with this version and watch out for the additional debug output?
https://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-TEST.2018-04-28.zip/download

:thanks:

[Gravitator]

This version is normal...
Build #2131 and #2130 Identical? Perhaps the installer influenced the landmark :confused:

[LoRd_MuldeR]

This version is normal...
Build #2131 and #2130 Identical?

Well, not identical, obviously. But only change is that I added more "debug" output, so we can see (hopefully) where exactly things go mad.

Perhaps the installer influenced the landmark :confused:

I don't know how this should be possible. The installer doesn't really do anything, except for extracting the EXE file (and stuff) to the chosen directory.

The LameXP EXE file that us extracted from the installer is really exactly the same one as contained in the ZIP archive.

So, if you see divergent behavior between build #2131 and build #2130, something different must have happened, at runtime, I suppose...

[Gravitator]

Reinstalling to the default directory eliminates the bug!

[LoRd_MuldeR]

Reinstalling to the default directory eliminates the bug!

Strange :confused:

Anyway, if you think that the problem is somehow related to the "install directory", please try running the special build (https://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-TEST.2018-04-28.zip/download) from the exact "install directory" where the problem occurs.

:thanks:

[Gravitator]

The program is affected by the dependence of the presence in the roots of the disk ... Only to trace this bug is not possible through a special version :( I'll wait for the final release :)

[LoRd_MuldeR]

The program is affected by the dependence of the presence in the roots of the disk ... Only to trace this bug is not possible through a special version :( I'll wait for the final release :)

If there is a problem, we should fix it before the final release.

But if you cannot it with the "special build", which is the same as previous build just with more diagnostic output added to the console, then I don't know what to do...

[LoRd_MuldeR]

LameXP v4.16 has been released :)
https://github.com/lordmulder/LameXP/releases/latest

Changes between v4.15 and v4.16 [2018-04-30]:
* Upgraded build environment to Microsoft Visual Studio 2017.6 (MSVC 19.13)
* Updated LAME encoder to v3.100 Final (2017-10-13), compiled with ICL 18.0 and MSVC 14.1
* Updated mpg123 decoder to v1.25.10 (2018-03-05), compiled with GCC 7.3.0
* Updated Opus encoder/decoder libraries to v1.3-beta-31 (2018-03-27) and Opus-Tools to v0.1.10-51 (2018-03-04)
* Updated Monkey's Audio binary to v4.33 (2017-12-01), compiled with ICL 18.0 and MSVC 15.5
* Updated FAAD decoder to v2.8.6 (2017-10-10), compiled with ICL 18.0 and MSVC 15.5
* Updated Vorbis decoder to OggDec v1.10.1+ (2015-03-19), using libVorbis v1.3.6 (2018-03-16)
* Updated ALAC decoder to refalac v1.64 (2017-05-19), compiled with ICL 18.0 and MSVC 15.5
* Updated WavPack decoder to v5.1.0 (2017-01-20), compiled with ICL 18.0 and MSVC 15.5
* Updated MediaInfo to v18.03.1+ (2018-04-19), compiled with ICL 18.2 and MSVC 15.6
* Updated GnuPG to v1.4.22 (2017-07-19), compiled with GCC 7.2.0
* Updated QAAC add-in (separate download) to QAAC v2.64 (2017-07-19), compiled with ICL 18.0 and MSVC 15.5
* Complete re-write of MediaInfo parsing code, now using XML-based MediaInfo output
* Improved auto-detection of max. parallel instances on computers with "fast" (i.e. SSD or similar) drive
* Some improvements to output file name generation code
* Added "Visual Elements" manifest for Windows 8+ "Start" screen tile
* Some more protection against "DLL pre-loading" attacks has been implemented

[SeeMoreDigital]

Fantastico... Many thanks :)

[manolito]

Tested, works fine, thanks a lot... :thanks:

[manolito]

Just found out that the latest version 18.05 of MediaInfo.exe (downloaded from the MediaArea website) cannot be used to replace the LameXP built-in version.

Probably something about Zenitram's changes to the XML output. Right now this is not a big issue, but considering the usual update cycle of LameXP it will be around 1 year until the next stable version. It would be nice if we could use a newer version of MediaInfo without having to install beta versions of LameXP.


Cheers
manolito

[LoRd_MuldeR]

Just found out that the latest version 18.05 of MediaInfo.exe (downloaded from the MediaArea website) cannot be used to replace the LameXP built-in version.

Probably something about Zenitram's changes to the XML output. Right now this is not a big issue, but considering the usual update cycle of LameXP it will be around 1 year until the next stable version. It would be nice if we could use a newer version of MediaInfo without having to install beta versions of LameXP.

LameXP v4.16 comes with a "custom" build of MediaInfo v18.03.1, which contains an additional patch (not contained in "official" MediaInfo v18.03.1 release) in order to fix a bug in XML output.

That bug had been introduced in v18.03 with:
Attachments: do not provide anymore attachments content in XML by default, reducing XML output size

The patch (which my "custom" build of MediaInfo v18.03.1 already contained) is now "officially" included in MediaInfo v18.05. According to the changelog, there were no other changes regarding XML output in MediaInfo v18.05.

I think you should test whether your MediaInfo.exe (downloaded from the MediaArea website) works correctly outside of LameXP – when called with options "--Output=XML" and "--Full" plus "--Cover_Data=base64".

[manolito]

I think you should test whether your MediaInfo.exe (downloaded from the MediaArea website) works correctly outside of LameXP – when called with options "--Output=XML" and "--Full" plus "--Cover_Data=base64".

Just did this with an MP3 containing a cover. The output looks OK to me, here is the result.txt file:
https://www.sendspace.com/file/mw2339

The commandline was:
Mediainfo.exe "--Output=XML" "--Full" "--Cover_Data=base64" i:\test.mp3 >i:\result.txt

LameXP rejects the file with a "format not recognized" error.


Cheers
manolito

[LoRd_MuldeR]

Just did this with an MP3 containing a cover. The output looks OK to me, here is the result.txt file:
https://www.sendspace.com/file/mw2339

The commandline was:
Mediainfo.exe "--Output=XML" "--Full" "--Cover_Data=base64" i:\test.mp3 >i:\result.txt

LameXP rejects the file with a "format not recognized" error.

Okay, I know why that happens: We check the "creatingLibrary" version in the XML output. When using the "built-in" MediaInfo binary, then the expected version of MediaInfo is known and thus the check will succeed – provided that the XML output is correct. But when using an "external" MediaInfo binary, the version of MediaInfo is not known beforehand, and therefore the internal (expected) version is set to UINT_MAX. This makes the "creatingLibrary" check always fail.

Please try with this version:
https://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-TEST.2018-05-10.zip/download

[manolito]

Yes, this test version fixes it, thanks a lot... :thanks:

It also seems that I can use this executable as a hotfix for the stable version (it does not have a built-in timebomb like the beta versions). Nice...


Cheers
manolito

[AndyTejral]

Hey, I just tried to use LameXP for the first time. And I can't make it work! Trying to convert wma to mp3. Isn't that possible? Here is the error message:



LameXP v4.16 (Build #2134), compiled on 2018-04-30 at 14:48:13

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

The format of this file is NOT supported:
C:/Users/Andy/Music/10,000 Maniacs/Our Time in Eden/01 Noah's Dove.wma

Container Format: Windows Media
Audio Format: Type: WMA, Version: 2, Bitrate: ≈168 kbps (Variable)

[manolito]

Congratulations, on your first post you already discovered a major bug in the latest LameXP version... :devil:

I can confirm your issue, WMA v2 sources are rejected by the current LameXP version. I went back to the previous stable version 4.15, and this version has no problems with these sources.

Time for a hotfix...


Cheers
manolito


And a general rant:
After going back to a previous stable version I noticed that even for stable versions there is a time bomb of 1 year. I think that this is plain stupid. For Alpha, Beta or RC versions I can understand, but not for stable versions. Users may have valid reasons to stick to older stable versions, this latest WMA bug is a good example. Please stop imposing your views on users...

[LoRd_MuldeR]

Hey, I just tried to use LameXP for the first time. And I can't make it work! Trying to convert wma to mp3. Isn't that possible? Here is the error message:



LameXP v4.16 (Build #2134), compiled on 2018-04-30 at 14:48:13

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

The format of this file is NOT supported:
C:/Users/Andy/Music/10,000 Maniacs/Our Time in Eden/01 Noah's Dove.wma

Container Format: Windows Media
Audio Format: Type: WMA, Version: 2, Bitrate: ≈168 kbps (Variable)

It appears that MediaInfo now reports the format version of WMA streams as "N" rather than "Version N", which is why your WMA file was not recognized correctly :rolleyes:

Please try with the new TEST build:
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2018-05-18/LameXP-ALPHA.2018-05-18.Release-Static.Build-2140.exe/download

[AndyTejral]

Well, that worked! And man, that's perhaps the first time I've really given my computer a workout. 99% CPU for 1.6 hours!

And not only that, I intercut the original wav, the wma I made from that wav, and the mp3 I made from the wma. I can't tell the difference!

Great program! Thanks a lot!

[manolito]

I can confirm that the Alpha build 2140 does solve the WMA v2 issue... :cool:

Any chance for a stable hotfix version?

The LameXP test versions are not really user friendly, they expire after 30 days, and installing a newer test version requires users to reenter all their settings. (And you used some dirty tricks to defeat users who just set the system date back to an earlier date... :devil: )

Having to wait for one whole year until the next stable version fixes the WMA issue is not an acceptable option IMO...


Cheers
manolito

[LoRd_MuldeR]

I can confirm that the Alpha build 2140 does solve the WMA v2 issue... :cool:

Any chance for a stable hotfix version?

I'm currently looking into a problem regarding the new FAAD version. Maybe I will make a new release after that issue has been resolved...

[manolito]

:thanks:

[Photon]

Hi all,

I have been using LameXP for over a year - excellent program! However, I'm running into a bug when trying to encode using AAC (qaac 2.66). I don't encounter this problem with either OPUS, MP3 or Vorbis.

I'm currently using Version 4.16, Build 2134.

The problem is this: under the advanced settings tab, when inputting a custom encoding parameter for AAC (in this case, simply: "--tvbr 87") the encode fails, every time.

When inspecting the log, I figured out what the problem was:

https://s15.postimg.cc/wdvdwa8qz/Screen_Shot_2018-06-01_at_10.10.59.png

As you can see, instead of replacing and overriding the default quality setting (--tvbr 91, which the slider is set to under the Compression tab), the custom setting that I want (--tvbr 87) is just appended to the command string, thus conflicting with the first setting. Naturally this means that the encode stops in its tracks before it can do anything. It throws up this message at the bottom:

https://s15.postimg.cc/s8khaainv/Screen_Shot_2018-06-01_at_10.31.17.png

Please let me know if you can replicate this. It's the only thing holding me back from using LameXP for AAC encoding (which is otherwise first class).

[LoRd_MuldeR]

Hi all,

I have been using LameXP for over a year - excellent program! However, I'm running into a bug when trying to encode using AAC (qaac 2.66). I don't encounter this problem with either OPUS, MP3 or Vorbis.

I'm currently using Version 4.16, Build 2134.

The problem is this: under the advanced settings tab, when inputting a custom encoding parameter for AAC (in this case, simply: "--tvbr 87") the encode fails, every time.

When inspecting the log, I figured out what the problem was:

https://s15.postimg.cc/wdvdwa8qz/Screen_Shot_2018-06-01_at_10.10.59.png

As you can see, instead of replacing and overriding the default quality setting (--tvbr 91, which the slider is set to under the Compression tab), the custom setting that I want (--tvbr 87) is just appended to the command string, thus conflicting with the first setting. Naturally this means that the encode stops in its tracks before it can do anything. It throws up this message at the bottom:

https://s15.postimg.cc/s8khaainv/Screen_Shot_2018-06-01_at_10.31.17.png

Please let me know if you can replicate this. It's the only thing holding me back from using LameXP for AAC encoding (which is otherwise first class).

Well, the "custom" parameters are simply appended to the command-line that is generated automatically. And, of course, the generated command-line must contain the switches for the selected RC mode.

If you try to set the RC mode via "custom" parameter too, RC mode will unavoidably appear in the command-line twice – as the program clearly says: "custom" parameters are not validated and you use them at your own risk.

Most CLI tools will allow to specify even "conflicting" switches, in which case simply the last option on the command-line will take effect. This way you can easily "override" options already set by the generated command-line.

But: It appears that QAAC does more "pedantic" checking and won't allow to "override" the already-set RC mode.

There is no easy solution for this, because we would need figure out any possible combination of "conflicting" options. And, if a "conflicting" option was detected, remove that option from the generated command-line...

(Maintaining a list of potentially "conflicting" options – for every supported encoder – would be a lot of work. Just to enable a use-case that was never really intended)

[Photon]

Well, the "custom" parameters are simply appended to the command-line that is generated automatically. And, of course, the generated command-line must contain the switches for the selected RC mode.

If you try to set the RC mode via "custom" parameter too, RC mode will unavoidably appear in the command-line twice – as the program clearly says: "custom" parameters are not validated and you use them at your own risk.

Most CLI tools will allow to specify even "conflicting" switches, in which case simply the last option on the command-line will take effect. This way you can easily "override" options already set by the generated command-line.

But: It appears that QAAC does more "pedantic" checking and won't allow to "override" the already-set RC mode.

There is no easy solution for this, because we would need figure out any possible combination of "conflicting" options. And, if a "conflicting" option was detected, remove that option from the generated command-line...

(Maintaining a list of potentially "conflicting" options – for every supported encoder – would be a lot of work. Just to enable a use-case that was never really intended)

Thanks for the explanation. So in short, there is no way of using a custom-defined bitrate or quality level for AAC in LameXP?

Would it be possible in that case to provide an option somehow tweak the TVBR slider so that we have more granular control? (Maybe an "advanced" slider activated by a checkbox, that allows the user to move up and down in increments of 1). That's the only solution I can think of for this but I don't know how feasible it would be to implement.

Other software allows you to select the TVBR quality level in increments of one right from the GUI, it's just that they don't have any easy was of importing your whole library in one go like LameXP does.

[LoRd_MuldeR]

Thanks for the explanation. So in short, there is no way of using a custom-defined bitrate or quality level for AAC in LameXP?

Yes. Obviously QAAC doesn't allow overwrite of previous options.

Other software allows you to select the TVBR quality level in increments of one right from the GUI, it's just that they don't have any easy was of importing your whole library in one go like LameXP does.

Probably a case of "Placebo Effect" ;)

From QAAC wiki (https://github.com/nu774/qaac/wiki/Encoder-configuration#tvbr-quality-steps):

https://i.imgur.com/nsvIWG8.png


From LameXP code:
static const int g_qaacVBRQualityLUT[16] = {0 ,9, 18, 27, 36, 45, 54, 63, 73, 82, 91, 100, 109, 118, 127, INT_MAX};

class QAACEncoderInfo : public AbstractEncoderInfo
{
virtual int valueCount(int mode) const
{
switch(mode)
{
case SettingsModel::VBRMode:
return 15;
break;
[...]
}
}
virtual int valueAt(int mode, int index) const
{
switch(mode)
{
case SettingsModel::VBRMode:
return g_qaacVBRQualityLUT[qBound(0, index , 14)];
break;
[...]
}
}
[...]
}

[Photon]

Probably a case of "Placebo Effect" ;)

From QAAC wiki (https://github.com/nu774/qaac/wiki/Encoder-configuration#tvbr-quality-steps):

https://i.imgur.com/nsvIWG8.png

Well, I just went away and encoded an album using TVBR 87 and 91 using another program... and you're right, exactly the same file size! Not a jot of difference between them. Never would have known that if I hadn't signed up here. Thanks MuldeR.

[LoRd_MuldeR]

LameXP v4.17 Alpha-3

Changes between v4.15 and v4.16 [2018-04-30]:
* Upgraded build environment to Microsoft Visual Studio 2017.7 (MSVC 19.14)
* Updated Opus encoder/decoder libraries to v1.3-RC-1 (2018-06-01) and Opus-Tools to v0.1.10-71 (2018-04-30)
* Updated MediaInfo to v18.05 (2018-05-09), compiled with ICL 18.2 and MSVC 15.7
* Downgraded FAAD to from v2.8 to v2.7 for now, because v2.8 is currently broken with certain MP4 files
* Fixed detection of certain WMA and AAC files (regression in LameXP v4.16)

[manolito]

I'm currently looking into a problem regarding the new FAAD version. Maybe I will make a new release after that issue has been resolved...

Looks to me like this is not gonna happen...
I won't bother with LameXP Alpha, Beta or RC versions any longer, it's just too annoying. I went back to the stable version 4.15 and updated a few tools, and this will do until the next stable version comes out...


Cheers
manolito

[RieGo]

thanks for your regular updates. still using this tool mainly for opus low bitrate encoding stuff :)
now there's one request i'd like to mention. in LameXP you can only choose between preset bitrate options. 8;16;24 beeing the lowest. now there is quite a big quality gap between 8 and 16 kbit/s in opus.
could you make it possible to somehow be able to set custom bitrate values?
thx

[LoRd_MuldeR]

thanks for your regular updates. still using this tool mainly for opus low bitrate encoding stuff :)
now there's one request i'd like to mention. in LameXP you can only choose between preset bitrate options. 8;16;24 beeing the lowest. now there is quite a big quality gap between 8 and 16 kbit/s in opus.
could you make it possible to somehow be able to set custom bitrate values?
thx

Hello,

for now you could just add "--bitrate <value>" to the custom parameters for OpusEnc, on "Adavanced Options" tab.

This will overwrite the bitrate selected on "Compression" tab.

But if you think that we should add more bitrate steps for Opus towards the lower end, then I could probably do that. Maybe adding 12 kbps and 20 kbps would suffice?

Regards.

[LoRd_MuldeR]

Hello,

for now you could just add "--bitrate <value>" to the custom parameters for OpusEnc, on "Adavanced Options" tab.

This will overwrite the bitrate selected on "Compression" tab.

But if you think that we should add more bitrate steps for Opus towards the lower end, then I could probably do that. Maybe adding 12 kbps and 20 kbps would suffice?

Regards.

Okay, I have adjusted the bitrate mappings for OpusEnc a bit. Can you please try with new TEST version?
https://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-TEST.2018-07-13.Release-Static.Build-2146.exe/download

[RieGo]

Okay, I have adjusted the bitrate mappings for OpusEnc a bit. Can you please try with new TEST version?
https://sourceforge.net/projects/muldersoft/files/LameXP/Testing/LameXP-TEST.2018-07-13.Release-Static.Build-2146.exe/download

I apologize for my late response, was on vacation.

just tried this new build and it works just as expected.
you are awesome! :)

[LoRd_MuldeR]

LameXP v4.17 Beta-1

Changes between v4.16 and v4.17 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.8 (MSVC 19.15)
* Updated Opus encoder/decoder libraries to v1.3-RC-1 (2018-06-01) and Opus-Tools to v0.1.10-71 (2018-04-30)
* Updated MediaInfo to v18.05 (2018-05-09), compiled with ICL 18.2 and MSVC 15.7
* Downgraded FAAD to from v2.8 to v2.7 for now, because v2.8 is currently broken with certain MP4 files
* Fixed detection of certain WMA and AAC files [regression in LameXP v4.16]

[LoRd_MuldeR]

LameXP v4.17 Beta-2

Changes between v4.16 and v4.17 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.8 (MSVC 19.15)
* Updated Opus encoder/decoder libraries to v1.3-RC-1 (2018-06-01) and Opus-Tools to v0.1.10-71 (2018-04-30)
* Updated MediaInfo to v18.05 (2018-05-09), compiled with ICL 18.2 and MSVC 15.7
* Downgraded FAAD to from v2.8 to v2.7 for now, because v2.8 is currently broken with certain MP4 files
* Fixed detection of certain WMA and AAC files [regression in LameXP v4.16]

[LoRd_MuldeR]

LameXP v4.17 RC-1

Changes between v4.16 and v4.17 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.8 (MSVC 19.15)
* Updated Opus encoder/decoder libraries to v1.3-RC2 (2018-09-27) and Opus-Tools to v0.2+2 (2018-09-30)
* Updated MediaInfo to v18.05 (2018-05-09), compiled with ICL 18.2 and MSVC 15.7
* Downgraded FAAD to from v2.8 to v2.7 for now, because v2.8 is currently broken with certain MP4 files
* Fixed detection of certain WMA and AAC files [regression in LameXP v4.16]

[LoRd_MuldeR]

LameXP v4.17 RC-4

Changes between v4.16 and v4.17 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.8 (MSVC 19.15)
* Updated Opus encoder/decoder libraries to v1.3 (2018-10-17) and Opus-Tools to v0.2+3 (2018-10-16)
* Updated MediaInfo to v18.05 (2018-05-09), compiled with ICL 18.2 and MSVC 15.7
* Updated GnuPG to v1.4.23 (2018-06-11), compiled with GCC 7.3.0
* Downgraded FAAD to from v2.8 to v2.7 for now, because v2.8 is currently broken with certain MP4 files
* Fixed detection of certain WMA and AAC files [regression in LameXP v4.16]
* Some improvements to the auto-update function, which is now using cURL instead of Wget
* Updated language files (big thank-you to all contributors !!!)

[danlock]

re: LameXP v4.17 RC-4

*grin* vielen Dank!

[ArnaudNime]

Hi,
Any plan to support DISCNUMBER tag ?

[LoRd_MuldeR]

LameXP v4.17 has been released :)
https://github.com/lordmulder/LameXP/releases/latest

Changes between v4.16 and v4.17 [2018-10-11]:
* Upgraded build environment to Microsoft Visual Studio 2017.8 (MSVC 19.15)
* Updated Opus encoder/decoder libraries to v1.3 (2018-10-17) and Opus-Tools to v0.2+3 (2018-10-16)
* Updated MediaInfo to v18.05 (2018-05-09), compiled with ICL 18.2 and MSVC 15.7
* Updated GnuPG to v1.4.23 (2018-06-11), compiled with GCC 7.3.0
* Downgraded FAAD to from v2.8 to v2.7 for now, because v2.8 is currently broken with certain MP4 files
* Fixed detection of certain WMA and AAC files [regression in LameXP v4.16]
* Some improvements to the auto-update function, which is now using cURL instead of Wget
* Updated language files (big thank-you to all contributors !!!)

[LoRd_MuldeR]

Hi,
Any plan to support DISCNUMBER tag ?

Probably not, sorry.

[Floatingshed]

Love the tool, so useful.

One minor thing, is it possible to have aac/mp4 files created as m4a? I have a large library of mp4 a/v files, it would be handy to differentiate between audio only and audio/video files.

Thanks.

[manolito]

Already answered in 2010... :D
Have a look here:
https://forum.doom9.org/showthread.php?p=1401725#post1401725

Cheers
manolito

[LoRd_MuldeR]

Already answered in 2010... :D
Have a look here:
https://forum.doom9.org/showthread.php?p=1401725#post1401725

Cheers
manolito

Actually things have changed quite a bit since then :)

Love the tool, so useful.

One minor thing, is it possible to have aac/mp4 files created as m4a? I have a large library of mp4 a/v files, it would be handy to differentiate between audio only and audio/video files.

Thanks.

If you really want to, you can achieve that via "Rename Output Files" feature, which can be found on the "Advanced Options" tab.

Go to the "File Extensions" section and click "Add Overwrite" button...

[manolito]

Actually things have changed quite a bit since then :)

Would you care to elaborate?
The only official file extension defined by the standard is .mp4
Has this changed in the meantime?

[LoRd_MuldeR]

Has this changed in the meantime?

Not really. This is why I still wouldn't add a “Save AAC/MP4 files with .m4a file extension” option, or something in that vein. Way too specific, and promoting the wrong idea.

If we added this today, tomorrow somebody would come along and requests the “Save Ogg/Vorbis files with .oga file extension” option.

Nonetheless, we have a pretty versatile rename feature now, which (among other things) can change the file extension to whatever you feel like. So it can handle (not only) the above use cases ;)

[SeeMoreDigital]

Actually things have changed quite a bit since then :)

If you really want to, you can achieve that via "Rename Output Files" feature, which can be found on the "Advanced Options" tab.

Go to the "File Extensions" section and click "Add Overwrite" button...Wow... When did you add this particular option?

[LoRd_MuldeR]

Wow... When did you add this particular option?

Around v4.12, I think.

[SeeMoreDigital]

Around v4.12, I think.
Ha... Around three years ago ;)

[LoRd_MuldeR]

LameXP v4.18 Alpha-4

Changes between v4.17 and v4.18 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.9 (MSVC 14.16)
* Updated Vorbis encoder to OggEnc v2.88 (2018-11-14), using libvorbis v1.3.6 with aoTuV b6.03 (2018)
* Updated FLAC encoder/decoder to v1.3.2+ Git (2018-09-19), compiled with ICL 19.0 and MSVC 14.16
* Updated Monkey's Audio binary to v4.41 (2018-12-05), compiled with ICL 19.0 and MSVC 14.16
* Updated mpg123 decoder to v1.25.10 (2018-03-05) and added 64-Bit binaries, compiled with GCC 8.2.1
* Updated MediaInfo to v18.08.1 (2018-09-10), compiled with ICL 19.0 and MSVC 14.16

Please report if any file types are not detected (decoded) properly anymore after the recent MediaInfo changes (https://forum.doom9.org/showpost.php?p=1849644&postcount=1629) ;)

[SeeMoreDigital]

Evening,

Over the last few months I've received a few PM's from people over on the AVS forum enquiring applications that can generate ALAC encodes. Is this something that could be implemented?

[LoRd_MuldeR]

Evening,

Over the last few months I've received a few PM's from people over on the AVS forum enquiring applications that can generate ALAC encodes. Is this something that could be implemented?

Well, since we already support ALAC decoding via refalac (https://github.com/nu774/qaac/wiki/refalac-usage), adding encoding support for ALAC wouldn't be too hard ;)

However I'm relucant to add encoding support for yet another "lossless" audio format.

We already have support for FLAC and Monkey's, where FLAC is the de facto standard for "lossless" audio today (with very good hardware support) and Monkey's is for those people who want that little bit of extra compression.

I see no advantage in ALAC format, as compression is no better than FLAC (actually slightly worse), whereas speed and playback support are inferior. Quality obviously is exactly the same for all "lossless" formats.

[danlock]

Decoding thought (1) and a suggestion (2):

1. Decoders: LameXP does not seem to detect an Opus (or Ogg, or other audio) stream inside a WebM container, claiming the file is invalid (it's uncommon to put Opus or Ogg inside a non-Ogg container, and LameXP presumably doesn't include a WebM decoder).

I'm not trying to open a can of worms here. I don't want you to make LameXP into anything you don't want it to be or turn it into a "extracts from all possible container formats" utility, which might reduce its focus and efficiency.

2. I like the Encoded with LameXP tag. However, I would rather it didn't overwrite an already-present informational tag when enabled. If I could remember to check the files prior to setting the metadata, I could ensure that wouldn't happen, but I often forget. A lot of musicians have bandcamp/etc. pages or other source or relevant data in that metadata tag.

Would it be possible to append " / Encoded with LameXP" to a pre-existing tag or, alternatively, to apply the LameXP metadata tag only if that field is blank/not present in the original file?

An opt-in configuration option could be created, possibly, for users to switch to the alternate behavior if you would rather the current behavior remain the default (have Encoded by LameXP written to the file by default when "Write meta information to encoded files" is enabled)

:thanks:

[LoRd_MuldeR]

1. Decoders: LameXP does not seem to detect an Opus (or Ogg, or other audio) stream inside a WebM container, claiming the file is invalid (it's uncommon to put Opus or Ogg inside a non-Ogg container, and LameXP presumably doesn't include a WebM decoder).

WebM is just a fancy name for VP8 or VP9 video with Vorbis or Opus audio stored in Matroska (MKV) container. But I agree that WebM input support would be much desired.

However, to the best of my knowledge, neither OggDec (official Vorbis decoder by Xiph.org) nor OpusDec (official Opus decoder by Xiph.org) support Matroska (MKV) files as input; only Xiph's own Ogg container is supported!

We probably could use "mkvextract" tool to demux the Vorbis or Opus track from the MKV container and have it stored as Ogg file, the we can invoke the OggDec or OpusDec decoder.

The problem here is that LameXP does not currently have a framework for performing an additional "demuxing" step before invoking the actual decoder; it is assumed we can select the suitable decoder for each file right away.

So, to make a long story short, this is quite doable, but would definitely require some general changes to the way how LameXP decodes input files. Not something I can do in the near term :o


2. I like the Encoded with LameXP tag. However, I would rather it didn't overwrite an already-present informational tag when enabled. If I could remember to check the files prior to setting the metadata, I could ensure that wouldn't happen, but I often forget. A lot of musicians have bandcamp/etc. pages or other source or relevant data in that metadata tag.

Well, things currently work like this: Any meta tags that you specify on the "Meta Data" tab take precedence over that meta tags that are detected from the input file.

The string "Encoded with LameXP" just happens to be the default comment value on the "Meta Data" tab. You can simply clear that value, if you don't like the comment from the input file to be replaced.

So, to solve this, we would need an option to append the meta tags specified on the "Meta Data" tab to the existing tags, instead of taking precedence over them.

But we probably would need that this option can be toggled separately for each meta tag (line), because for most of the tags we probably do not want that they are appended...

(either that, or we come up with a completely different method to sneak the "Encoded with LameXP" string into the comment field)

[danlock]

(either that, or we come up with a completely different method to sneak the "Encoded with LameXP" string into the comment field)

For tag styles/versions that support it, LameXP's text could be placed in the <ENCODED BY> field. :)

That would prevent LameXP from interfering with the comment field entirely.

[LoRd_MuldeR]

LameXP v4.18 Alpha-6
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2019-02-11/LameXP-ALPHA.2019-02-11.Release-Static.Build-2206.exe/download

Changes between v4.17 and v4.18 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.9 (MSVC 14.16)
* Updated Vorbis encoder to OggEnc v2.88 (2018-11-14), using libvorbis v1.3.6 with aoTuV b6.03 (2018)
* Updated FLAC encoder/decoder to v1.3.2+ Git (2018-09-19), compiled with ICL 19.0 and MSVC 14.16
* Updated Monkey's Audio binary to v4.41 (2018-12-05), compiled with ICL 19.0 and MSVC 14.16
* Updated mpg123 decoder to v1.25.10 (2018-03-05) and added 64-Bit binaries, compiled with GCC 8.2.1
* Updated MediaInfo to v18.12 (2018-12-10), compiled with ICL 19.0 and MSVC 14.16

[tablerocker]

Update search fails here (Win 8.1 x64). Of course I can just download the newest version, but I wanted to let you know.

LameXP 4.1.7.1 build 2188

Checking your Internet connection...

Connecting to host: www.der-postillon.com

* Trying 172.217.22.51...
* TCP_NODELAY set
* Connected to www.der-postillon.com (172.217.22.51) port 80 (#0)
> HEAD / HTTP/1.1
> Host: www.der-postillon.com
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
> Accept: */*
< HTTP/1.1 301 Moved Permanently
< Location: https://www.der-postillon.com/
< Content-Type: text/html; charset=UTF-8
< Date: Sun, 24 Feb 2019 18:59:30 GMT
< Expires: Sun, 24 Feb 2019 18:59:30 GMT
< Cache-Control: private, max-age=0
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Transfer-Encoding: chunked
< Accept-Ranges: none
< Vary: Accept-Encoding
* Connection #0 to host www.der-postillon.com left intact
DONE: Transfer completed successfully.

Connecting to host: rationalqm.us

DONE: Transfer completed successfully.

Connecting to host: www.uw.edu.pl

* Trying 193.0.115.152...
* TCP_NODELAY set
* Connected to www.uw.edu.pl (193.0.115.152) port 80 (#0)
> HEAD / HTTP/1.1
> Host: www.uw.edu.pl
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
> Accept: */*
* HTTP 1.0, assume close after body
< HTTP/1.0 302 Found
< Location: https://www.uw.edu.pl/
< Server: uw-lb
* HTTP/1.0 connection set to keep alive!
< Connection: Keep-Alive
< Content-Length: 0
* Connection #0 to host www.uw.edu.pl left intact
DONE: Transfer completed successfully.

Connecting to host: www.apache.org

* Trying 40.79.78.1...
* TCP_NODELAY set
* Connected to www.apache.org (40.79.78.1) port 80 (#0)
> HEAD / HTTP/1.1
> Host: www.apache.org
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
> Accept: */*
< HTTP/1.1 200 OK
< Date: Sun, 24 Feb 2019 18:59:31 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Last-Modified: Sun, 24 Feb 2019 18:10:20 GMT
< ETag: "f295-582a7bcace87f"
< Accept-Ranges: bytes
< Content-Length: 62101
< Vary: Accept-Encoding
< Cache-Control: max-age=3600
< Expires: Sun, 24 Feb 2019 19:59:31 GMT
< Content-Type: text/html
* Connection #0 to host www.apache.org left intact
DONE: Transfer completed successfully.

Connecting to host: www.baidu.com

* Trying 103.235.46.39...
* TCP_NODELAY set
* Connected to www.baidu.com (103.235.46.39) port 80 (#0)
> HEAD / HTTP/1.1
> Host: www.baidu.com
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
> Accept: */*
< HTTP/1.1 200 OK
< Server: bfe/1.0.8.18
< Date: Sun, 24 Feb 2019 18:59:32 GMT
< Content-Type: text/html
< Content-Length: 277
< Last-Modified: Mon, 13 Jun 2016 02:50:23 GMT
< Connection: Keep-Alive
< ETag: "575e1f6f-115"
< Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
< Pragma: no-cache
< Accept-Ranges: bytes
* Connection #0 to host www.baidu.com left intact
DONE: Transfer completed successfully.

----

Internet connection is operational, checking for updates online...

Trying update mirror:
http://www.muldersoft.keepfree.de/

Connecting to host: www.muldersoft.keepfree.de

DONE: Transfer completed successfully.

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `be9cd47c5b43f403.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://mulder.pe.hu/

Connecting to host: mulder.pe.hu

DONE: Transfer completed successfully.

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `6582489e74046ae4.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://gitlab.com/lamexp/lamexp/raw/gh-pages/

Connecting to host: gitlab.com

DONE: Transfer completed successfully.

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `eea858eb24352c05.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://lordmulder.github.io/LameXP/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `541327f772a0dfc3.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://lamexp.osdn.io/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `f7662bdde5678dcd.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://muldersoft.lima-city.de/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `13d1d4fdb414db56.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://muldersoft.sourceforge.net/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `cee093be878f0f50.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://muldersoft.co.nf/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `07b6d8ad25984733.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://mulder.bplaced.net/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `de2222ed62d546eb.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://muldersoft.com/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `618a5ecc80fecd29.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://muldersoft.bitbucket.io/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `9f788e65db0ef866.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://x264-launcher.osdn.io/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `123477e0c070119a.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://lamexp.sourceforge.net/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `c45e70527610d4fc.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://mulder.000webhostapp.com/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `8093d6da2ae3ce46.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://muldersoft.chickenkiller.com/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `abf0d8485690bb29.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://muldersoft.square7.ch/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `5d7e4e61cd453f9e.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://www.tricksoft.de/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `24b502b839843b53.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://repo.or.cz/LameXP.git/blob_plain/gh-pages:/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `9dcd6d0e55ee3d39.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://www.muldersoft.keepfree.de/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `b497b9285de1d801.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://mulder.pe.hu/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `d176183dbb39030d.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

Trying update mirror:
http://gitlab.com/lamexp/lamexp/raw/gh-pages/

Downloading update information:

DONE: Transfer completed successfully.

Downloading signature file:

DONE: Transfer completed successfully.

Download completed, verifying signature:

gpgv: can't open `e56d721a5d252299.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

[LoRd_MuldeR]

Update search fails here (Win 8.1 x64). Of course I can just download the newest version, but I wanted to let you know.

LameXP 4.1.7.1 build 2188

Well, it looks like the verification of the GPG signature fails, every time, on your machine, because access to the downloaded .sig is denied for an incomprehensible reason:
gpgv: can't open `6582489e74046ae4.sig'
gpgv: verify signatures failed: file open error
Exited with code 2

Bad signature detected, take care !!!

There is no reasonable explanation why this should be happening. Also, it works flawlessly for me, with the same program version and operating system:

https://i.imgur.com/PqeYk0im.png (https://i.imgur.com/PqeYk0i.png)

So I can only presume that this caused by so-called "anti-virus" software going on a rampage once again... and again... and again... and again... and again... and again... :rolleyes:

(If you feel like doing some more in-depth analysis of the issue, check out Process Monitor (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon))

[hanskroll]

Hello, not sure whether to post this here, so please correct me if I'm wrong.

I am encountering two 'bugs' (latest LameXP build 4.17 Final-1 2188, on Windows 10 Pro 1809).

The file I am trying to convert is a flac 192 kHz 24 bits, to:

1. aac/mp4 (profile auto), CBR 320kbps: encoding fails. Error code 0x0000 and 0x0001 "could not open AAC encoder". I have tried many different options for this format, yet they always fail to encode.
2. opus: encoding succeeds. But it cuts off the first half second or so from the start of the track.

Any idea why this occurs, and what might be the solution? If there is more information needed, please let me know.

[LoRd_MuldeR]

Hello, hanskroll.

1. aac/mp4 (profile auto), CBR 320kbps: encoding fails. Error code 0x0000 and 0x0001 "could not open AAC encoder". I have tried many different options for this format, yet they always fail to encode.

What AAC encoder are you using? Are you using Nero AAC or QAAC? Also, please post your log, so I can have a look!

2. opus: encoding succeeds. But it cuts off the first half second or so from the start of the track.

I'm not quite sure about this one. But I'm not the developer of the Opus encoder (opusenc), I'm just calling the Opus encoder and pass in the input file – as with any other encoder in LameXP.

So, I don't think there is anything on the LameXP side that might be causing this.

If you think there is anything wrong with the Opus encoder, you should try to reproduce it with opusenc (https://sourceforge.net/projects/muldersoft/files/Opus%20Tools/opus-tools.2018-10-24.zip/download) directly (not via LameXP), and then discuss your findings with the Opus developers...

[hanskroll]

Hello, thanks so much for your (quick) reply!

I'm using everything that came with LameXP, so it's the Nero AAC encoder. I will try to figure out and test results with QAAC. Here's the error output:

LameXP v4.17 (Build #2188), compiled on 2018-11-10 at 15:28:47

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

C:/Users/****/AppData/Local/Temp/51ba36340709e014/lxp_flac.exe -d -F -f -o C:\Users\****\AppData\Local\Temp\51ba36340709e014\153e3d8201b4b954.wav "C:\Users\****\Downloads\file.flac"

flac 1.3.2
Copyright (C) 2000-2009 Josh Coalson, 2011-2016 Xiph.Org Foundation
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/****/AppData/Local/Temp/51ba36340709e014/lxp_sox.exe --i C:\Users\****\AppData\Local\Temp\51ba36340709e014\153e3d8201b4b954.wav

Input File : 'C:\Users\****\AppData\Local\Temp\51ba36340709e014\153e3d8201b4b954.wav'
File Size : 418M
Bit Rate : 9.22M
Sample Encoding: 24-bit Signed Integer PCM

Exited with code: 0x0000

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

"C:/Program Files (x86)/MuldeR/LameXP/neroAacEnc.exe" -cbr 320000 -if C:\Users\****\AppData\Local\Temp\51ba36340709e014\153e3d8201b4b954.wav -of "C:\Users\****\Downloads\file.mp4"

ERROR: could not open AAC encoder
*************************************************************
* *
* Nero AAC Encoder *
* Copyright 2009 Nero AG *
* All Rights Reserved Worldwide *
* *
* Package build date: Feb 18 2010 *
* Package version: 1.5.4.0 *
* *
* See -help for a complete list of available parameters. *
* *
*************************************************************

Exited with code: 0x0001

As for the opus, I will try your suggestions of opusenc. Thanks again!

[LoRd_MuldeR]

I'm using everything that came with LameXP, so it's the Nero AAC encoder. I will try to figure out and test results with QAAC. Here's the error output:

"C:/Program Files (x86)/MuldeR/LameXP/neroAacEnc.exe" -cbr 320000 -if C:\Users\****\AppData\Local\Temp\51ba36340709e014\153e3d8201b4b954.wav -of "C:\Users\****\Downloads\file.mp4"

ERROR: could not open AAC encoder

Not quite sure, but I think this is some kind of "internal" error in Nero AAC encoder. Maybe we can pin down the exact conditions. Does it happen only with 320 kbps?

Unfortunately, development of Nero AAC encoder has been discontinued. There was no update for years.

[lvqcl]

AFAIK, NeroAAC doesn't support 192 kHz input. QAAC will automatically resample it to 48 kHz, but NeroAAC cannot do this.

[hanskroll]

Yes, unfortunately it happens with whatever quality, bitrate or profile I select. I indeed also feared it was because of the 192 khz, but could not find any documents about this online (quick search though). Anyway thanks to both for your answers!

[hanskroll]

Hello again. First of all came back to confirm I have been able to successfully convert 192kHz FLAC to 48kHz AAC/MP4, by simply replacing the Nero encoder for the QAAC (thanks to the great manual included in LameXP).

I have two remaining questions.

1. I am unable to disable artwork when converting. Track -> Show details -> Artwork -> Right mouse button on cover -> Clear Artwork. This deletes the artwork in LameXP itself, however is still present in the metadata of the file after the encoding completed. My example is from FLAC to AAC/MP4. Also, selecting multiple files and deleting the artwork, only deletes it from the one you've clicked on: not all those you've selected. Am I doing something wrong in this process?
2. Again about AAC/MP4: Is it somehow possible to change the output from .mp4 container to the .m4a (https://en.wikipedia.org/wiki/MPEG-4_Part_14#.MP4_versus_.M4A) extension?

[LoRd_MuldeR]

1. I am unable to disable artwork when converting. Track -> Show details -> Artwork -> Right mouse button on cover -> Clear Artwork. This deletes the artwork in LameXP itself, however is still present in the metadata of the file after the encoding completed. My example is from FLAC to AAC/MP4. Also, selecting multiple files and deleting the artwork, only deletes it from the one you've clicked on: not all those you've selected. Am I doing something wrong in this process?

There cannot be any cover artwork (or other meta information) in the encoded file, unless it is explicitly embedded.

But LameXP won't (and can't) instruct QAAC to embed any meta-tags – including cover artwork – unless that meta-data is actually available in LameXP and the option "Write meta information to encoded files" is enabled.

You can double-check this in the LameXP log. For this purpose, double-click on the corresponding item in the list, after the encoding process has finished. Then check the QAAC command-line.

Anyway, how do you know that encoded file still contains cover artwork? For example, if your playback application shows cover artwork for the file, it does not necessarily mean the artwork was loaded from the file itself!

(The playback application might load cover artwork from a separate "cover.jpg" in the same directory, or even fetch it from the Internet)


2. Again about AAC/MP4: Is it somehow possible to change the output from .mp4 container to the .m4a (https://en.wikipedia.org/wiki/MPEG-4_Part_14#.MP4_versus_.M4A) extension?

If you really which to change the file extension of AAC/MP4 files to the non-standard .m4a extension, you can do this by simply renaming those files, of course ;)

In LameXP, you could use the "Rename output files" option, on the "Advanced options" tab. Click on "File extensions" and then "Add overwrite".

[hanskroll]

Thanks for your reply.

1. I have one single FLAC file in an otherwise empty folder, with a cover included in its metadata. There is no other file (jpg) in the same folder, nor does my playback application fetch data over the internet. Unchecking the "Write meta information to encoded files" in the Meta Data tab discards the artwork cover, but this option however locks me out from actually renaming other data, for example album title.
2. My apologies, I have overlooked the overwrite option in LameXP, let alone renaming it manually myself.. (Reason for testing with the non-standard extension is because VLC Android is treating the .mp4 as a video file, and Kodi Android TV doesn't even show the file in its folder..)

Thanks again!

[LoRd_MuldeR]

1. I have one single FLAC file in an otherwise empty folder, with a cover included in its metadata. There is no other file (jpg) in the same folder, nor does my playback application fetch data over the internet. Unchecking the "Write meta information to encoded files" in the Meta Data tab discards the artwork cover, but this option however locks me out from actually renaming other data, for example album title.

I just double-checked that. When I encode a source file that has cover artwork, it gets embedded with QAAC, as expected:
LameXP v4.18 (Build #2208), compiled on 2019-03-16 at 21:35:30

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

C:/Users/MuldeR/AppData/Local/Temp/7def5916b439d522/lxp_mpg123.exe -v --utf8
-w C:\Users\MuldeR\AppData\Local\Temp\7def5916b439d522\15782f6fc678129d.wav
"E:\Music\Alte Sau - Alte Sau\01 Bose Winde.mp3"

High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
version 1.25.10; written and copyright by Michael Hipp and others
free software (LGPL) without any warranty but with best wishes
Decoder: x86-64 (AVX)
Trying output module: wav, device:
C:\Users\MuldeR\AppData\Local\Temp\7def5916b439d522\15782f6fc678129d.wav
Playing MPEG stream 1 of 1: E:\Music\Alte Sau - Alte Sau\01 Bose Winde.mp3 ...
MPEG 1.0 L III cbr320 44100 stereo
Title: Böse Winde Artist: Alte Sau
Album: Alte Sau
Year: 2014 Genre: Unknown
[3:48] Decoding of E:\Music\Alte Sau - Alte Sau\01 Bose Winde.mp3 finished.

Exited with code: 0x0000

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

"C:/Program Files (x86)/MuldeR/LameXP v4.14/qaac.exe" --tvbr 63 --quality 2 --title "Böse Winde"
--artist "Alte Sau" --album "Alte Sau" --genre "Punk Rock" --comment "Encoded with LameXP"
--date 2017 --track 1 --artwork
C:/Users/MuldeR/AppData/Local/Temp/7def5916b439d522/b30bddaf9b31e9c3.jpg -d . -o
"C:\Users\MuldeR\Music\!\01 Bose Winde.mp4"
C:\Users\MuldeR\AppData\Local\Temp\7def5916b439d522\15782f6fc678129d.wav

qaac 2.64, CoreAudioToolbox 7.10.5.0
01 Bose Winde.mp4
AAC-LC Encoder, TVBR q64, Quality 96
10082304/10082304 samples processed in 0:03.125
Overall bitrate: 118.644kbps
Optimizing...done

Exited with code: 0x0000

Cover artwork does not get embedded with QAAC, after I cleared it in LameXP, also as expected:
LameXP v4.18 (Build #2208), compiled on 2019-03-16 at 21:35:30

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

C:/Users/MuldeR/AppData/Local/Temp/7def5916b439d522/lxp_mpg123.exe -v --utf8
-w C:\Users\MuldeR\AppData\Local\Temp\7def5916b439d522\e007818421b31884.wav
"E:\Music\Alte Sau - Alte Sau\01 Bose Winde.mp3"

High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
version 1.25.10; written and copyright by Michael Hipp and others
free software (LGPL) without any warranty but with best wishes
Decoder: x86-64 (AVX)
Trying output module:
wav, device: C:\Users\MuldeR\AppData\Local\Temp\7def5916b439d522\e007818421b31884.wav
Playing MPEG stream 1 of 1: E:\Music\Alte Sau - Alte Sau\01 Bose Winde.mp3 ...
MPEG 1.0 L III cbr320 44100 stereo
Title: Böse Winde Artist: Alte Sau
Album: Alte Sau
Year: 2014 Genre: Unknown
[3:48] Decoding of E:\Music\Alte Sau - Alte Sau\01 Bose Winde.mp3 finished.

Exited with code: 0x0000

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

"C:/Program Files (x86)/MuldeR/LameXP v4.14/qaac.exe" --tvbr 63 --quality 2 --title "Böse Winde"
--artist "Alte Sau" --album "Alte Sau" --genre "Punk Rock" --comment "Encoded with LameXP"
--date 2017 --track 1 -d . -o "C:\Users\MuldeR\Music\!\01 Bose Winde (2).mp4"
C:\Users\MuldeR\AppData\Local\Temp\7def5916b439d522\e007818421b31884.wav

qaac 2.64, CoreAudioToolbox 7.10.5.0
01 Bose Winde (2).mp4
AAC-LC Encoder, TVBR q64, Quality 96
10082304/10082304 samples processed in 0:03.093
Overall bitrate: 118.644kbps
Optimizing...done

Exited with code: 0x0000

Note how there no "--artwork" switch passed to QAAC in the second case. Looks like everything works correct on the LameXP side.

[tablerocker]

Regarding my last post (https://forum.doom9.org/showpost.php?p=1866700&postcount=1576) about failed update search (signature verification failed):
I wanted to investigate today but now it works without errors.

So as you assumed the error probably originated from an external source (Windows firewall, Avast behaviour shield, ...).

I didn't change anything besides patching already present programs. However, error is gone now.

[LoRd_MuldeR]

Regarding my last post (https://forum.doom9.org/showpost.php?p=1866700&postcount=1576) about failed update search (signature verification failed):
I wanted to investigate today but now it works without errors.

So as you assumed the error probably originated from an external source (Windows firewall, Avast behaviour shield, ...).

I didn't change anything besides patching already present programs. However, error is gone now.

Hmm, interesting...

Because the GnuPG process was apparently "blocked" from accessing the downloaded signature file – after the download itself seemed to have completed just fine – the Avast thingy would be my bet.

[LoRd_MuldeR]

LameXP v4.18 Alpha-8

Changes between v4.17 and v4.18 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.9 (MSVC 14.16)
* Updated Vorbis encoder to OggEnc v2.88 (2018-11-14), using libvorbis v1.3.6 with aoTuV b6.03 (2018)
* Updated FLAC encoder/decoder to v1.3.2+ Git (2018-09-19), compiled with ICL 19.0 and MSVC 14.16
* Updated Monkey's Audio binary to v4.41 (2018-12-05), compiled with ICL 19.0 and MSVC 14.16
* Updated mpg123 decoder to v1.25.10 (2018-03-05) and added 64-Bit binaries, compiled with GCC 8.2.1
* Updated MediaInfo to v18.12 (2018-12-10), compiled with ICL 19.0 and MSVC 14.16

[danlock]

LameXP v4.18 Alpha-8
Experimental VS2019 binaries[...]

Thank you, LoRd_MuldeR. :)

I'm a little surprised you didn't include the latest stable build of libopus (https://opus-codec.org/release/stable/2019/04/12/libopus-1_3_1.html), but—to be fair—that was released on 12 April, so you might not have had time to include it in v4.18 Alpha-8.

:cool:

I use Win 8.1 x64 too. In your opinion, would it be good for me to try the experimental VS2019 binaries? Are you actively looking for feedback on those?

FWIW, I had to manually download LameXP for a couple of months also due to an auto-update error, but I don't know whether it's related to what's been discussed. That is no longer a problem. (The only AV software I use is the built-in Windows Defender.)

Thanks!

[LoRd_MuldeR]

LameXP v4.18 Beta-1

Changes between v4.17 and v4.18 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.9 (MSVC 14.16)
* Updated Opus encoder/decoder libraries to v1.3.1 (2019-04-14) and Opus-Tools to v0.2+3 (2018-10-16)
* Updated Vorbis encoder to OggEnc v2.88 (2018-11-14), using libvorbis v1.3.6 with aoTuV b6.03 (2018)
* Updated FLAC encoder/decoder to v1.3.2+ Git (2018-09-19), compiled with ICL 19.0 and MSVC 14.16
* Updated Monkey's Audio binary to v4.41 (2018-12-05), compiled with ICL 19.0 and MSVC 14.16
* Updated mpg123 decoder to v1.25.10 (2018-03-05) and added 64-Bit binaries, compiled with GCC 8.2.1
* Updated MediaInfo to v19.04 (2019-04-23), compiled with ICL 19.0 and MSVC 14.16
* Fixed encoding with Nero AAC encoder for input sampling rate less than 8 KHz or greater than 96 KHz

[MrVideo]

I just started using LameXP (4.18 Beta-1 2216) and have run across a silly thing:

LameXP wants to extract the flac audio as WAV files. How about an option that skips that skip and go directly to flac, for those of us who just want to extract the singular flac file into its separate pieces. I know, others will want an option to go directly to MP3, etc. Just a thought.

So far, I'm liking this program.

[LoRd_MuldeR]

LameXP wants to extract the flac audio as WAV files. How about an option that skips that skip and go directly to flac, for those of us who just want to extract the singular flac file into its separate pieces. I know, others will want an option to go directly to MP3, etc. Just a thought.

Not quite sure what you mean with "extract the singular flac file into its separate pieces" :confused:

But if you want to split an existing FLAC file into multiple segments, then LameXP might not be right tool for you. LameXP is primarily an audio file converter, i.e. it converts audio files from one format to another.

In general, the given input file will first be decoded to an uncompressed WAV file, using the suitable decoder, and then the that "intermediary" WAV file is sent to the selected encoder.

If and only if the selected encoder is able read the respective input format directly, then the "decoding" step will be skipped.

[MrVideo]

Not quite sure what you mean with "extract the singular flac file into its separate pieces" :confused:
A single flac file that contains more than one song. For example, an entire CD converted to a single flac file, hence the cue file.

If you know of a program that can take the single flac file, along with the cue file, and extract the individual songs without recoding, I'd appreciate it.

The process of converting to WAV first and then to flac doesn't result in any quality loss, since both are lossless. Going directly from flac to flac, without any recoding, would be faster.

[LoRd_MuldeR]

A single flac file that contains more than one song. For example, an entire CD converted to a single flac file, hence the cue file.

If you know of a program that can take the single flac file, along with the cue file, and extract the individual songs without recoding, I'd appreciate it.

Have you looked at CUETools (http://cue.tools/wiki/CUETools) yet?

[LoRd_MuldeR]

LameXP v4.18 Beta-2

Changes between v4.17 and v4.18 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.9 (MSVC 14.16)
* Updated Opus encoder/decoder libraries to v1.3.1 (2019-04-14) and Opus-Tools to v0.2+3 (2018-10-16)
* Updated Vorbis encoder to OggEnc v2.88 (2018-11-14), using libvorbis v1.3.6 with aoTuV b6.03 (2018)
* Updated FLAC encoder/decoder to v1.3.2+ Git (2018-09-19), compiled with ICL 19.0 and MSVC 14.16
* Updated Monkey's Audio binary to v4.73 (2019-05-15), compiled with ICL 19.0 and MSVC 14.16
* Updated mpg123 decoder to v1.25.10 (2018-03-05) and added 64-Bit binaries, compiled with GCC 8.2.1
* Updated MediaInfo to v19.04 (2019-04-23), compiled with ICL 19.0 and MSVC 14.16[/COLOR]
* Fixed encoding with Nero AAC encoder for input sampling rate less than 8 KHz or greater than 96 KHz

[stax76]

I would like to request better High DPI support, maybe use fonts instead of images, like FontAwesome & Segoe-MDL2-Assets

[LoRd_MuldeR]

I would like to request better High DPI support, maybe use fonts instead of images, like FontAwesome & Segoe-MDL2-Assets

The GUI is made with Qt. So, we pretty much have to rely on the "High DPI support" that is offered by Qt. And, in fact, I already tried to fix the layout for non-standard DPI settings in a few places. What is your specific problem?

As far as the icons and images are concerned: Even though Qt is supposed to support SVG, replacing all the bitmap icons and images with vector graphics would be a difficult task...

[stax76]

At 288 DPI none of your apps are usable.

[LoRd_MuldeR]

At 288 DPI none of your apps are usable.

What do you mean with "usable"?

The highest "scaling" setting Windows allows me to select with my frumpy "Full HD" screen is 175% (probably equivalent to 168 DPI), and even with that setting I can see no serious problems with that setting:

https://i.imgur.com/pd5EebK.png

(expect maybe that the icons appear a bit small compared to the fonts)

[stax76]

Win 7 supports 288 DPI.

https://postimg.cc/LJ275HJS

[LoRd_MuldeR]

Win 7 supports 288 DPI.

https://postimg.cc/LJ275HJS

Is that Windows 10, or is that Windows 7 with some "Windows 10 Lookalike" theme?

Anyways, I think Windows 10 made some improvements on "High DPI" support compared to Windows 7. Looks pretty "okay" to me with Windows 10 and the "175%" settings:
https://i.imgur.com/YAbzk8x.png

[stax76]

It's Win 10 (bought for 6,50 € on eBay).

[stax76]

400 % zoom

https://postimg.cc/fSfS5jDJ

[stax76]

For StaxRip rendering font symbols into bitmaps at run time has been working out well, fonts are vector graphics based I guess.

mkvtoolnix gui which is also qt based uses images, it does run time scaling I would guess, it looks OK:

https://postimg.cc/LJ7Bvd3D

[MrVideo]

Have you looked at CUETools (http://cue.tools/wiki/CUETools) yet?
I have now. What I don't like is that I can't set the output directory path to be the same path as to where the cue file comes from.

I've found the forum and will post a query there about this issue.

[MrVideo]

I noticed that if I extract the audio from a flac cue file and recode the extracted WAV files to FLAC and then do another cue file, the audio files from the first cue file are done again, resulting in song (2).flac files.

Instead of doing that, might I suggest that the user is warned that such-n-such file has already been encoded and then get shown these typical four options: No - No to all - Yes - Yes to all

Yes, the easiest way around this is to clear the list before doing the next one. But, if you forget, there is no way out of it. Just a user friendly suggestion.

[LoRd_MuldeR]

LameXP v4.18 Beta-4

Changes between v4.17 and v4.18 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.9 (MSVC 14.16)
* Updated Opus encoder/decoder libraries to v1.3.1 (2019-04-14) and Opus-Tools to v0.2+3 (2018-10-16)
* Updated Vorbis encoder to OggEnc v2.88 (2018-11-14), using libvorbis v1.3.6 with aoTuV b6.03 (2018)
* Updated FLAC encoder/decoder to v1.3.2+ Git (2018-09-19), compiled with ICL 19.0 and MSVC 14.16
* Updated Monkey's Audio binary to v4.73 (2019-05-15), compiled with ICL 19.0 and MSVC 14.16
* Updated mpg123 decoder to v1.25.10 (2018-03-05) and added 64-Bit binaries, compiled with GCC 8.2.1
* Updated MediaInfo to v19.04 (2019-04-23), compiled with ICL 19.0 and MSVC 14.16
* Fixed encoding with Nero AAC encoder for input sampling rate less than 8 KHz or greater than 96 KHz

[Gravitator]

Привет!
Is it possible to force the output format *.aac? FDK, QAAC gives *.mp4

[LoRd_MuldeR]

Привет!
Is it possible to force the output format *.aac? FDK, QAAC gives *.mp4

The correct file extension for AAC stored in MP4 container, which is what all encoders create (by default), is ".mp4".

You can use the "Advanced Options" → "Rename Output Files" → "File Extensions" feature of LameXP in order to rename the files from ".mp4" to ".aac", but the content of the file would still be AAC stored in MP4 container!

If ADTS (https://wiki.multimedia.cx/index.php/ADTS) (Audio Data Transport Stream) format is what you desire, then you can try to use QAAC encoder and manually add the "--adts" option to "Custom Encoder Parameters".

[Gravitator]

Thanks! It turned out that it is better to change to *.mp4a (Jet Audio does not see a simple *.mp4).
Is there a cover shutdown?
The option of the AAC encoder is available > check the availability of the update > sometimes I get a connection error with the server (maintenance at night?)> reboot LameXP v4.17 Final - AAC is blocked (unlocking occurs after a successful connection with the server).

[LoRd_MuldeR]

Is there a cover shutdown?

:confused:

The option of the AAC encoder is available > check the availability of the update > sometimes I get a connection error with the server (maintenance at night?)> reboot LameXP v4.17 Final - AAC is blocked (unlocking occurs after a successful connection with the server).

Are you referring to the LameXP "auto-update" feature?

Well, I have to rely on a bunch of "free" web-hosting offerings, which can be slow or even unavailable at peak times. Therefore, LameXP has a built-in list of many update mirrors. It will continue to pick a random mirror from the list until it has found a "working" one. That is why you may see individual mirrors fail, but sooner or later the update check should always succeed.

Anyhow, I don't see how all that is related to AAC encoders! If LameXP finds a supported AAC encoder in its install directory during startup, then the AAC encoding option will be enabled. Otherwise it won't. That's it ;)

(Launch LameXP with option "--console" for more details)

[Gravitator]

:confused:
Delete album image :)

Are you referring to the LameXP "auto-update" feature?
Disabled.

Anyhow, I don't see how all that is related to AAC encoders! If LameXP finds a supported AAC encoder in its install directory during startup, then the AAC encoding option will be enabled. Otherwise it won't. That's it ;)

The check at the AAC encoders was skipped! In the folder were enc_fhgaac.dll, fdkaac.exe, fhgaacenc.exe, qaac64.exe

[LoRd_MuldeR]

The check at the AAC encoders was skipped! In the folder were enc_fhgaac.dll, fdkaac.exe, fhgaacenc.exe, qaac64.exe

Again, not quite sure what you mean :confused:

To make it clear again: LameXP looks for one of the supported AAC encoder in its install directory at startup. If and only if a supported AAC encoder is found, then AAC encoding support will be enabled. Otherwise it won't.

Note that if multiple encoders are available, then QAAC takes precedence over FDKAAC, FDKAAC takes precedence over FhgAacEnc, and FhgAacEnc takes precedence over NeroAAC.

(As said before, launch LameXP with option "--console" to get more details)

[manolito]

Note that if multiple encoders are available, then QAAC takes precedence over FDKAAC, FDKAAC takes precedence over FhgAacEnc, and FhgAacEnc takes precedence over NeroAAC.

Interesting...
What are these "precedence" decisions based upon? Audible encoding quality?

I think there is general consent that QAAC beats all its competitors, but FDKAAC above FhgAacEnc? Highly questionable. And NeroAAC getting the red lantern is also disputable. At least at "normal" bitrates it is certainly every bit as good as the Fraunhofer offerings.

Just my two cents...

[LoRd_MuldeR]

Interesting...
What are these "precedence" decisions based upon? Audible encoding quality?

Inspired by listening tests (e.g. see here (http://listening-tests.hydrogenaud.io/igorc/aac-96-a/results.html))

As you say, most people seem to agree that QAAC (Apple AAC) is superior these days. And Nero AAC consistently takes the last place, when compared to QAAC and FhG AAC.

Not quite sure about "FhG" flavors (FDKAAC vs. FhgAacEnc). But considering that FDKAAC is available as OpenSource, whereas the FhgAacEnc DLL needs to be "exfiltrated" from old versions of Winamp and hasn't been updated in years...

Anyhow, the precedence is not all that important! It's only needed for conflict resolution, if more than one encoder happens to be present.

LameXP will always show what encoder it is using, on the "Compression" tab. You can easily correct things, if it is not using the intended AAC encoder. Just install whatever AAC encoder you wish to use, and that's it ;)

[T-Hawk]

I have been using LameXP to convert a bunch of wav files to mp3. I noticed that it appears to be assigning a track volume. I am not sure why it is doing this since I don't have normalization checked and haven't changed any of the default settings.

I converted a test track and it assigned -10.0dB. I converted the same track with Audacity and Foobar and it left that tag blank. I am viewing the tags in MediaMonkey. When played the LameXP converted track is quieter than the other two as expected.

I can delete the tagged value and the song returns to normal volume, but any idea why this is happening? I expected a raw conversion with no added tweaks to the sound.

[manolito]

This made me curious, so I converted a WAV to MP3 using standard settings. No normalizing. The log looks like this:
lxp_lame.exe --nohist -q 2 -V 1 --tt "The Jam" --tc "Kodiert mit LameXP" --tn 1 "D:\The Jam.wav" "D:\The Jam.mp3"

LAME 3.100 64bits (http://lame.sf.net)
CPU features: SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 19383 Hz - 19916 Hz
Encoding D:\The Jam.wav to D:\The Jam.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=1)
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
Writing LAME Tag...done
ReplayGain: -4.9dB

Exited with code: 0x0000

So Lame obviously writes a ReplayGain tag by default. My TagScanner software just does not see this tag (maybe the version is too old). Since I do not use any player software which honors this tag I never had any problems with it. But there is a command line switch in Lame.exe which disables calculation of the ReplayGain value, maybe adding "--noreplaygain" to the custom MP3 parameters in LameXP will fix it for you.

[LoRd_MuldeR]

I have been using LameXP to convert a bunch of wav files to mp3. I noticed that it appears to be assigning a track volume. I am not sure why it is doing this since I don't have normalization checked and haven't changed any of the default settings.

I converted a test track and it assigned -10.0dB. I converted the same track with Audacity and Foobar and it left that tag blank. I am viewing the tags in MediaMonkey. When played the LameXP converted track is quieter than the other two as expected.

I can delete the tagged value and the song returns to normal volume, but any idea why this is happening? I expected a raw conversion with no added tweaks to the sound.

It is important to understand that the ReplayGain tag that LAME is creating (by default) is nothing but a meta information. It does not alter the volume of the audio file at all!

ReplayGain normalization happens, if at all, at playback time. So, IMO, there are only two possible situations:

If you do want ReplayGain to normalize the volume of you media files, then you need a playback software that supports ReplayGain and your media files need to contain proper ReplayGain meta information.
The latter is exactly what LAME is doing (by default). In other words, LAME prepares the created MP3 files for ReplayGain processing, but the actual processing happens in your playback software.

If you do not want ReplayGain to normalize the volume of you media files, then use a playback software that does not support ReplayGain –or– just disable the ReplayGain feature of your playback software.
Either way, as long as ReplayGain is disabled (or unsupported) in your playback software, the ReplayGain meta information that may be present in the media file will simply be ignored.

tl;dr If you don't like ReplayGain processing, then disable it in your playback software ;)

[T-Hawk]

It is important to understand that the ReplayGain tag that LAME is creating (by default) is nothing but a meta information. It does not alter the volume of the audio file at all!

ReplayGain normalization happens, if at all, at playback time. So, IMO, there are only two possible situations:

If you do want ReplayGain to normalize the volume of you media files, then you need a playback software that supports ReplayGain and your media files need to contain proper ReplayGain meta information.
The latter is exactly what LAME is doing (by default). In other words, LAME prepares the created MP3 files for ReplayGain processing, but the actual processing happens in your playback software.

If you do not want ReplayGain to normalize the volume of you media files, then use a playback software that does not support ReplayGain –or– just disable the ReplayGain feature of your playback software.
Either way, as long as ReplayGain is disabled (or unsupported) in your playback software, the ReplayGain meta information that may be present in the media file will simply be ignored.

tl;dr If you don't like ReplayGain processing, then disable it in your playback software ;)

I would rather just not have to deal with it. It's not always obvious if a particular player is using ReplayGain and how to disable it. Foobar and Audacity are not adding the "meta information" to the best of my knowledge and both are using the LAME encoder. So I assume it is a LAMEXP default and not a LAME default. Looks like I will just use Foobar from now on and have to go back to the files I've already converted with LAMEXP and remove the track volume info.

[manolito]

But there is a command line switch in Lame.exe which disables calculation of the ReplayGain value, maybe adding "--noreplaygain" to the custom MP3 parameters in LameXP will fix it for you.

Have you tried this workaround?

[LoRd_MuldeR]

So I assume it is a LAMEXP default and not a LAME default. Looks like I will just use Foobar from now on and have to go back to the files I've already converted with LAMEXP and remove the track volume info.

Nope, it really is a LAME default. LameXP does nothing to enable ReplayGain tag generation. Though, LameXP does northing to disable this default behavior of LAME either.

See LAME manpage:
https://linux.die.net/man/1/lame

--noreplaygain
Disable ReplayGain analysis.
By default ReplayGain analysis is enabled. This switch disables it.

Manually add switch "--noreplaygain" to custom parameters, if you really wish to suppress ReplayGain tag creation.

[LoRd_MuldeR]

LameXP v4.18 Beta-5

Changes between v4.17 and v4.18 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.9 (MSVC 14.16)
* Updated LAME encoder to v3.100.1-SVN (2019-07-23), compiled with ICL 19.0 and MSVC 14.16
* Updated Opus encoder/decoder libraries to v1.3.1 (2019-04-14) and Opus-Tools to v0.2+3 (2018-10-16)
* Updated Vorbis encoder to OggEnc v2.88 (2018-11-14), using libvorbis v1.3.6 with aoTuV b6.03 (2018)
* Updated FLAC encoder/decoder to v1.3.2+ Git (2018-09-19), compiled with ICL 19.0 and MSVC 14.16
* Updated Monkey's Audio binary to v4.73 (2019-05-15), compiled with ICL 19.0 and MSVC 14.16
* Updated mpg123 decoder to v1.25.11 (2019-07-18) and added 64-Bit binaries, compiled with GCC 9.1.0
* Updated MediaInfo to v19.07 (2019-07-16), compiled with ICL 19.0 and MSVC 14.16
* Fixed encoding with Nero AAC encoder for input sampling rate less than 8 KHz or greater than 96 KHz

[manolito]

Since development of LameXP has slowed down considerably, more and more users of the latest stable version now get this at startup:

https://i.postimg.cc/FF0hFwM1/Update.png (https://postimages.org/)

After clicking "Ignore" there is another message that the update check was declined (accompanied by a very silly sound clip).

Please, if you are too busy to release a new stable version within one year, could you please add an option (maybe hidden in the settings file) to skip this update reminder? It really annoys me to no end... :mad:


Cheers
manolito

[LoRd_MuldeR]

Sorry, for the delay. I'm planning to release a new version soon™. In the meantime you can check out RC-2.

LameXP v4.18 RC-2

Changes between v4.17 and v4.18 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2017.9 (MSVC 14.16)
* Updated LAME encoder to v3.100.1-SVN (2019-07-23), compiled with ICL 19.0 and MSVC 14.16
* Updated Opus encoder/decoder libraries to v1.3.1 (2019-04-14) and Opus-Tools to v0.2+3 (2018-10-16)
* Updated Vorbis encoder to OggEnc v2.88 (2018-11-14), using libvorbis v1.3.6 with aoTuV b6.03 (2018)
* Updated FLAC encoder/decoder to v1.3.2+ Git (2018-09-19), compiled with ICL 19.0 and MSVC 14.16
* Updated Monkey's Audio binary to v4.73 (2019-05-15), compiled with ICL 19.0 and MSVC 14.16
* Updated mpg123 decoder to v1.25.11 (2019-07-18) and added 64-Bit binaries, compiled with GCC 9.1.0
* Updated MediaInfo to v19.07 (2019-07-16), compiled with ICL 19.0 and MSVC 14.16
* Added Japanese (日本語) translation, thanks to Maboroshin <pc.genkaku.in>
* Fixed encoding with Nero AAC encoder for input sampling rate less than 8 KHz or greater than 96 KHz

[LoRd_MuldeR]

LameXP v4.18 has been released :)
https://github.com/lordmulder/LameXP/releases/latest

Changes between v4.17 and v4.18 [2019-12-18]:
* Upgraded build environment to Microsoft Visual Studio 2017.9 (MSVC 14.16)
* Updated LAME encoder to v3.100.1-SVN (2019-07-23), compiled with ICL 19.0 and MSVC 14.16
* Updated Opus encoder/decoder libraries to v1.3.1 (2019-04-14) and Opus-Tools to v0.2+3 (2018-10-16)
* Updated Vorbis encoder to OggEnc v2.88 (2018-11-14), using libvorbis v1.3.6 with aoTuV b6.03 (2018)
* Updated FLAC encoder/decoder to v1.3.2+ Git (2018-09-19), compiled with ICL 19.0 and MSVC 14.16
* Updated Monkey's Audio binary to v4.73 (2019-05-15), compiled with ICL 19.0 and MSVC 14.16
* Updated mpg123 decoder to v1.25.11 (2019-07-18) and added 64-Bit binaries, compiled with GCC 9.1.0
* Updated MediaInfo to v19.07 (2019-07-16), compiled with ICL 19.0 and MSVC 14.16
* Added Japanese (日本語) translation, thanks to Maboroshin <pc.genkaku.in>
* Fixed encoding with Nero AAC encoder for input sampling rate less than 8 KHz or greater than 96 KHz
* Updated language files (big thank-you to all contributors !!!)

[manolito]

:thanks:

[Taurus]

:thanks:

[SeeMoreDigital]

Many, many thanks :)

[VzK]

Thanks for the update!

[danlock]

:thanks::D:cool::) @LoRd_MuldeR

[Ma-Xell]

https://img8.uploadhouse.com/fileuploads/28033/28033548e3d90919bf0d7bee29342534694690aa.png

[tablerocker]

Thank you for the update!
Little flaw:
On http://lamexp.sourceforge.net/doc/Changelog.html#lamexp-v4.18-unreleased it says 4.18 is unreleased.
And the given email address lacks the domain ".de".

[LoRd_MuldeR]

Little flaw:
On http://lamexp.sourceforge.net/doc/Changelog.html#lamexp-v4.18-unreleased it says 4.18 is unreleased.

Latest changelog should now be available.

[Aggregate]

The latest LameXP release has stolen all multimedia files associations to itself (mp3, m3u, wav, etc.), however I don't remember any question about files associations during the installation. Is this normally ? What's the reason for these files associations for LameXP, if it's not an audio player, but it's formats encoder ?

[SeeMoreDigital]

How odd @Aggregate,

What operating system (and version) are your running?

Personally, I'm running Windows 10 Home v1909 [18363.535]...


Cheers

[Aggregate]

I'm using Windows 10 Pro v1909 [18363.535]
I would like to clarify that I've been using LameXP for quite long time, but any previous versions didn't touch file associations, except the last one.

[SeeMoreDigital]

I'm using Windows 10 Pro v1909 [18363.535]
I would like to clarify that I've been using LameXP for quite long time, but any previous versions didn't touch file associations, except the last one.Odd... There was no such problem when I installed the newest version of LameXP...

[LoRd_MuldeR]

The latest LameXP release has stolen all multimedia files associations to itself (mp3, m3u, wav, etc.), however I don't remember any question about files associations during the installation. Is this normally ? What's the reason for these files associations for LameXP, if it's not an audio player, but it's formats encoder ?

Not quite sure what is happening.

What I can say for sure is that the shell integration code, which would be relevant here, has not been changed since some time around 2015:
https://github.com/lordmulder/LameXP/commits/master/src/ShellIntegration.cpp

What this code does: For each "supported" file extension (.wav, .mp3, etc. pp.), it will lookup the file type that is currently registered to that extension. Then, for each of those existing file types, it will add a custom command ("ConvertWithLameXP"). The standard "open" command of the file type is not modified. Also, for file extensions that already are registered to a file type, the file extension to file type mapping is not changed.

If and only if one of the "supported" file extensions is not registered to a file type at all (which rarely happens, but is possible), then a mapping to the our own "LameXP.SupportedAudioFile" file type is created for that file extension.

Works as expected for me. This is on Windows 10 v1909:
https://i.imgur.com/KpStPIe.png

[sloot]

Hi LoRd_MuldeR.

Thank you for your work on such a great program.
I would like to make some suggestions.

Please support Freeware Advanced Audio Coder
Please support the input file TrueHD Audio, DTS-HD MA.
Please add an option (tools -> configuration ->) to skip the update reminder (remove pop-up and annoying music).
Please add an option (tools -> configuration ->) splash screen disabled. Or a DisableSplashScreen = false or true line in the LameXP-Portable.ini file.

Thanks for everything!

Regards.

[LoRd_MuldeR]

Please support Freeware Advanced Audio Coder

FAAC is a subpar AAC encoder. And, to the best of knowledge, development is long dead. We already support much better alternatives, including NeroAAC, FhgAacEnc as well as QAAC (Apple AAC).

Please support the input file TrueHD Audio, DTS-HD MA.

Well, if a suitable CLI encoder was available, I would be able too look into this. Unfortunately, development of Valdec (AC-3 Filter tools), which is currently used for AC-3 and DTS decoding, seems to be dead too.

Please add an option (tools -> configuration ->) to skip the update reminder (remove pop-up and annoying music).

The regular (14 days) update check can be disabled, as always. The notification about using a deprecated version can't be skipped, an that is for a reason.

Please add an option (tools -> configuration ->) splash screen disabled. Or a DisableSplashScreen = false or true line in the LameXP-Portable.ini file.

Technically, this is not easily possible. The splash screen is not shown for entertainment purposes (only). Some fundamental initialization work is actually going on while you are seeing the splash screen ;)

In theory, it would be possible to simply show no UI at all while the initialization work is going. But be aware that this would not speed things up at all!

However, I think it would be confusing for the users, if they start the program but nothing is showing up. It would take several seconds (or even longer for some people), until the LameXP window finally pops up.

[tormento]

I have many AAC encoders and I would like to put in the LameXP directory, each one in its folder, so I can choose which one to use.

List includes: FhgAACenc, neroAacEnc, Qaac, fdkaac and ffmpeg with fdk-aac.dll.

Do you think it is possible?

[MrVideo]

Using latest release, which I installed a little bit ago, on my XP-SP3 system (ya, I know, but this computer has a purpose).

While extracting a .cue file, a song was skipped and a reason was not given. I couldn't find a log file. If I play the .cue file via VLC, the song plays just fine. I skipped to it, played several seconds and then skipped to the next song. No issues.

What could cause LameXP to skip a song?

Update: While adding some more .cue files, one skipped two files and the next one skipped 13 of 19, 13 of 19 and 14 of 19 (3 disc set). Ouch!

OK, this is getting downright nasty. Disc 1 and 2 of a 2 disc set skipped all 20 tracks (each disc).

[LoRd_MuldeR]

Using latest release, which I installed a little bit ago, on my XP-SP3 system (ya, I know, but this computer has a purpose).

While extracting a .cue file, a song was skipped and a reason was not given. I couldn't find a log file. If I play the .cue file via VLC, the song plays just fine. I skipped to it, played several seconds and then skipped to the next song. No issues.

What could cause LameXP to skip a song?

Update: While adding some more .cue files, one skipped two files and the next one skipped 13 of 19, 13 of 19 and 14 of 19 (3 disc set). Ouch!

OK, this is getting downright nasty. Disc 1 and 2 of a 2 disc set skipped all 20 tracks (each disc).

You can run application with command-line option "--console" for more detailed logging.

Just for the notes: I use the CUE sheet import function all the time to import .cue files produced by EAC (Exact Audio Copy) and didn't encounter any "skipped" tracks yet.

Anyway, maybe you can see something in the log.

BTW: Is this a CUE sheet with just one big WAVE file that will be split into tracks, or does it use a separate WAVE file for each track? In the latter case, it could be that some files were not found for some reasons.

(For example, if you choose the "wrong" character encoding, it is possible that file names containing "special" characters are interpreted wrongly)

[MrVideo]

You can run application with command-line option "--console" for more detailed logging.
Great, did that.
Just for the notes: I use the CUE sheet import function all the time to import .cue files produced by EAC (Exact Audio Copy) and didn't encounter any "skipped" tracks yet.
I've done others as well.
Anyway, maybe you can see something in the log.
All I get is: Splitting has failed !!!
It shows the details for the track, but gives no reason for the failure.
BTW: Is this a CUE sheet with just one big WAVE file that will be split into tracks, or does it use a separate WAVE file for each track? In the latter case, it could be that some files were not found for some reasons.
Sorry, I should have stipulated that it is one big flac file.

This is really weird. I went back to one of the discs where all 20 tracks were skipped and now it only skipped 7. Same with disc 2 of the 2 disc set.

The HDD is local, not networked (as in a NAS).

You have an XP issue. Something is failing internally when the program is run on an XP SP3 32bit system. I installed it on one of my Win7-64 bit systems and the flac file imported and split just fine. The earlier beta build that I had worked just fine on the XP system.

BTW, I thought that LameXP was 64bit as well. But it installed in the X86 location.

[SeeMoreDigital]

@MrVideo,

Can you upload your .cue sheet?

[MrVideo]

I restarted the splitting on the Win7 box. All was good until I got to this disc, in which track 14 was skipped:
REM GENRE "Pop - 1960s"
REM DATE 1997
REM DISCID 1C0BCB13
REM COMMENT "ExactAudioCopy v1.3"
PERFORMER "Simon & Garfunkel"
TITLE "Old Friends [Disc 1]"
REM COMPOSER ""
FILE "Simon & Garfunkel - Old Friends [Disc 1].flac" WAVE
TRACK 01 AUDIO
TITLE "Bleecker Street"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "The Sound Of Silence"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 02:42:62
INDEX 01 02:44:37
TRACK 03 AUDIO
TITLE "The Sun Is Burning"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 05:50:00
INDEX 01 05:51:37
TRACK 04 AUDIO
TITLE "Wednesday Morning, 3 A.M."
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 08:38:12
INDEX 01 08:39:62
TRACK 05 AUDIO
TITLE "He Was My Brother"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 10:54:12
INDEX 01 10:55:50
TRACK 06 AUDIO
TITLE "Sparrow"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 13:44:62
INDEX 01 13:46:25
TRACK 07 AUDIO
TITLE "Peggy-O"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 16:33:62
INDEX 01 16:35:25
TRACK 08 AUDIO
TITLE "Benedictus"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 19:00:50
INDEX 01 19:02:12
TRACK 09 AUDIO
TITLE "Somewhere They Can't Find Me"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 21:40:12
INDEX 01 21:41:50
TRACK 10 AUDIO
TITLE "We've Got a Groovy Thing Goin'"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 24:16:25
INDEX 01 24:17:62
TRACK 11 AUDIO
TITLE "Leaves That Are Green"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 26:15:50
INDEX 01 26:17:25
TRACK 12 AUDIO
TITLE "Richard Cory"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 28:38:12
INDEX 01 28:39:62
TRACK 13 AUDIO
TITLE "I Am A Rock"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 31:35:37
INDEX 01 31:37:00
TRACK 14 AUDIO
TITLE "The Sound Of Silence (Single Version)"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 34:26:50
INDEX 01 34:28:25
TRACK 15 AUDIO
TITLE "Homeward Bound"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 37:33:62
INDEX 01 37:35:25
TRACK 16 AUDIO
TITLE "Blues Run The Game"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 40:04:25
INDEX 01 40:06:00
TRACK 17 AUDIO
TITLE "Kathy's Song"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 42:57:50
INDEX 01 42:59:25
TRACK 18 AUDIO
TITLE "April Come She Will"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 46:16:62
INDEX 01 46:18:25
TRACK 19 AUDIO
TITLE "Flowers Never Bend With The Rainfall"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 48:07:50
INDEX 01 48:09:25
Tracks 5,6 and 18 were skipped:
REM GENRE "Pop - 1960s"
REM DATE 1997
REM DISCID 110D3A15
REM COMMENT "ExactAudioCopy v1.3"
PERFORMER "Simon & Garfunkel"
TITLE "Old Friends [Disc 2]"
REM COMPOSER ""
FILE "Simon & Garfunkel - Old Friends [Disc 2].flac" WAVE
TRACK 01 AUDIO
TITLE "Patterns"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Cloudy"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 02:45:37
INDEX 01 02:47:00
TRACK 03 AUDIO
TITLE "The Dangling Conversation"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 05:08:50
INDEX 01 05:10:25
TRACK 04 AUDIO
TITLE "Scarborough Fair; Canticle"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 07:47:25
INDEX 01 07:49:00
TRACK 05 AUDIO
TITLE "The 59th Street Bridge Song (Feelin' Groovy)"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 10:59:25
INDEX 01 11:01:00
TRACK 06 AUDIO
TITLE "For Emily, Whenever I May Find Her"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 12:54:62
INDEX 01 12:56:50
TRACK 07 AUDIO
TITLE "7 O'Clock News; Silent Night"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 15:01:50
INDEX 01 15:03:12
TRACK 08 AUDIO
TITLE "A Hazy Shade Of Winter"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 17:06:12
INDEX 01 17:08:00
TRACK 09 AUDIO
TITLE "At The Zoo"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 01 19:25:47
TRACK 10 AUDIO
TITLE "A Poem On The Underground Wall"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 21:48:25
INDEX 01 21:50:00
TRACK 11 AUDIO
TITLE "Red Rubber Ball"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 01 26:20:22
TRACK 12 AUDIO
TITLE "Blessed"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 01 28:49:05
TRACK 13 AUDIO
TITLE "Anji"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 01 32:28:67
TRACK 14 AUDIO
TITLE "A Church Is Burning"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 01 34:58:22
TRACK 15 AUDIO
TITLE "Fakin' It"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 38:25:62
INDEX 01 38:27:50
TRACK 16 AUDIO
TITLE "Save The Life Of My Child"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 41:45:25
INDEX 01 41:46:62
TRACK 17 AUDIO
TITLE "America"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 01 44:35:67
TRACK 18 AUDIO
TITLE "You Don't Know Where Your Interest Lies"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 48:11:37
INDEX 01 48:13:25
TRACK 19 AUDIO
TITLE "Punky's Dilemma"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 50:32:12
INDEX 01 50:34:12
TRACK 20 AUDIO
TITLE "Comfort And Joy"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 52:47:25
INDEX 01 52:48:62
TRACK 21 AUDIO
TITLE "Star Carol"
PERFORMER "Simon & Garfunkel"
REM COMPOSER ""
INDEX 00 54:38:37
INDEX 01 54:40:00
Not an XP issue, as many tracks were skipped in a couple of other discs that I did after this. Then I stopped.

[SeeMoreDigital]

Give this a try: -

PERFORMER "Simon & Garfunkel"
TITLE "Old Friends [Disc 2]"
REM DATE 1997
REM GENRE Pop - 1960s

FILE "Simon & Garfunkel - Old Friends [Disc 2].flac" WAVE

TRACK 01 AUDIO
TITLE "Patterns"
PERFORMER "Simon & Garfunkel"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Cloudy"
PERFORMER "Simon & Garfunkel"
INDEX 01 02:47:00
TRACK 03 AUDIO
TITLE "The Dangling Conversation"
PERFORMER "Simon & Garfunkel"
INDEX 01 05:10:25
TRACK 04 AUDIO
TITLE "Scarborough Fair: Canticle"
PERFORMER "Simon & Garfunkel"
INDEX 01 07:49:00
TRACK 05 AUDIO
TITLE "The 59th Street Bridge Song (Feelin' Groovy)"
PERFORMER "Simon & Garfunkel"
INDEX 01 11:01:00
TRACK 06 AUDIO
TITLE "For Emily, Whenever I May Find Her"
PERFORMER "Simon & Garfunkel"
INDEX 01 12:56:50
TRACK 07 AUDIO
TITLE "7 O'Clock News: Silent Night"
PERFORMER "Simon & Garfunkel"
INDEX 01 15:03:12
TRACK 08 AUDIO
TITLE "A Hazy Shade Of Winter"
PERFORMER "Simon & Garfunkel"
INDEX 01 17:08:00
TRACK 09 AUDIO
TITLE "At The Zoo"
PERFORMER "Simon & Garfunkel"
INDEX 01 19:25:47
TRACK 10 AUDIO
TITLE "A Poem On The Underground Wall"
PERFORMER "Simon & Garfunkel"
INDEX 01 21:50:00
TRACK 11 AUDIO
TITLE "Red Rubber Ball"
PERFORMER "Simon & Garfunkel"
INDEX 01 26:20:22
TRACK 12 AUDIO
TITLE "Blessed"
PERFORMER "Simon & Garfunkel"
INDEX 01 28:49:05
TRACK 13 AUDIO
TITLE "Anji"
PERFORMER "Simon & Garfunkel"
INDEX 01 32:28:67
TRACK 14 AUDIO
TITLE "A Church Is Burning"
PERFORMER "Simon & Garfunkel"
INDEX 01 34:58:22
TRACK 15 AUDIO
TITLE "Fakin' It"
PERFORMER "Simon & Garfunkel"
INDEX 01 38:27:50
TRACK 16 AUDIO
TITLE "Save The Life Of My Child"
PERFORMER "Simon & Garfunkel"
INDEX 01 41:46:62
TRACK 17 AUDIO
TITLE "America"
PERFORMER "Simon & Garfunkel"
INDEX 01 44:35:67
TRACK 18 AUDIO
TITLE "You Don't Know Where Your Interest Lies"
PERFORMER "Simon & Garfunkel"
INDEX 01 48:13:25
TRACK 19 AUDIO
TITLE "Punky's Dilemma"
PERFORMER "Simon & Garfunkel"
INDEX 01 50:34:12
TRACK 20 AUDIO
TITLE "Comfort And Joy"
PERFORMER "Simon & Garfunkel"
INDEX 01 52:48:62
TRACK 21 AUDIO
TITLE "Star Carol"
PERFORMER "Simon & Garfunkel"
INDEX 01 54:40:00

[LoRd_MuldeR]

MrVideo, I tried with the second .cue file you provided, and apparently it was imported just as expected, with all 21 tracks:

(since I don't have your original FLAC file, I simply used a dummy WAVE file of appropriate length, but otherwise the .cue file is totally unchanged)

Looks like the CUE sheet parser found all 21 tracks, and they all have a positive length:
https://i.imgur.com/6zCbtGB.png

Also, all 21 tracks have been imported successfully, with all 21 imported files being non-empty:
https://i.imgur.com/f82OBOg.png

Does importing that same .cue file look differently on your side? If so, can you please provide screenshots showing the same phases as above?

[MrVideo]

Before I do any of the above, I just imported 10 cue sheets from other discs and all imported just fine.

[MrVideo]

Give this a try: -

PERFORMER "Simon & Garfunkel"
TITLE "Old Friends [Disc 2]"
REM DATE 1997
REM GENRE Pop - 1960s

FILE "Simon & Garfunkel - Old Friends [Disc 2].flac" WAVE

TRACK 01 AUDIO
TITLE "Patterns"
PERFORMER "Simon & Garfunkel"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Cloudy"
PERFORMER "Simon & Garfunkel"
INDEX 01 02:47:00
TRACK 03 AUDIO
TITLE "The Dangling Conversation"
PERFORMER "Simon & Garfunkel"
INDEX 01 05:10:25
TRACK 04 AUDIO
TITLE "Scarborough Fair: Canticle"
PERFORMER "Simon & Garfunkel"
INDEX 01 07:49:00
TRACK 05 AUDIO
TITLE "The 59th Street Bridge Song (Feelin' Groovy)"
PERFORMER "Simon & Garfunkel"
INDEX 01 11:01:00
TRACK 06 AUDIO
TITLE "For Emily, Whenever I May Find Her"
PERFORMER "Simon & Garfunkel"
INDEX 01 12:56:50
TRACK 07 AUDIO
TITLE "7 O'Clock News: Silent Night"
PERFORMER "Simon & Garfunkel"
INDEX 01 15:03:12
TRACK 08 AUDIO
TITLE "A Hazy Shade Of Winter"
PERFORMER "Simon & Garfunkel"
INDEX 01 17:08:00
TRACK 09 AUDIO
TITLE "At The Zoo"
PERFORMER "Simon & Garfunkel"
INDEX 01 19:25:47
TRACK 10 AUDIO
TITLE "A Poem On The Underground Wall"
PERFORMER "Simon & Garfunkel"
INDEX 01 21:50:00
TRACK 11 AUDIO
TITLE "Red Rubber Ball"
PERFORMER "Simon & Garfunkel"
INDEX 01 26:20:22
TRACK 12 AUDIO
TITLE "Blessed"
PERFORMER "Simon & Garfunkel"
INDEX 01 28:49:05
TRACK 13 AUDIO
TITLE "Anji"
PERFORMER "Simon & Garfunkel"
INDEX 01 32:28:67
TRACK 14 AUDIO
TITLE "A Church Is Burning"
PERFORMER "Simon & Garfunkel"
INDEX 01 34:58:22
TRACK 15 AUDIO
TITLE "Fakin' It"
PERFORMER "Simon & Garfunkel"
INDEX 01 38:27:50
TRACK 16 AUDIO
TITLE "Save The Life Of My Child"
PERFORMER "Simon & Garfunkel"
INDEX 01 41:46:62
TRACK 17 AUDIO
TITLE "America"
PERFORMER "Simon & Garfunkel"
INDEX 01 44:35:67
TRACK 18 AUDIO
TITLE "You Don't Know Where Your Interest Lies"
PERFORMER "Simon & Garfunkel"
INDEX 01 48:13:25
TRACK 19 AUDIO
TITLE "Punky's Dilemma"
PERFORMER "Simon & Garfunkel"
INDEX 01 50:34:12
TRACK 20 AUDIO
TITLE "Comfort And Joy"
PERFORMER "Simon & Garfunkel"
INDEX 01 52:48:62
TRACK 21 AUDIO
TITLE "Star Carol"
PERFORMER "Simon & Garfunkel"
INDEX 01 54:40:00

Skipped the same three tracks,

[MrVideo]

OK, reverting back to the original .cue file, it now skips 4 tracks. The same three + #10.

First image is the same, in that all 21 tracks are listed. Here is after importing:

It isn't a jpg file, it is a png file.

[LoRd_MuldeR]

First image is the same, in that all 21 tracks are listed.

And also all 21 tracks are shown with a positive length (duration) and with a reasonable start index in the CUE import dialog? – just to be sure.

Here is after importing:

It isn't a jpg file, it is a png file.

This would indicate that something goes wrong during the actual splitting/importing, not in the CUE file parser.

Please run the program with command-line option "--console", so that you'll have a log window, and see if any errors or warnings (or anything unusual) appear in the log during the import step.

(You can just provide the complete log, if you want to)

[MrVideo]

And also all 21 tracks are shown with a positive length (duration) and with a reasonable start index in the CUE import dialog? – just to be sure.
Yes. Starts at 0 time.
This would indicate that something goes wrong during the actual splitting/importing, not in the CUE file parser.
Sorry that I didn't make that clear in that everything looks good during the .cue file parsing. I didn't see any weird numbers.
Please run the program with command-line option "--console", so that you'll have a log window, and see if any errors or warnings (or anything unusual) appear in the log during the import step.
Here is the png of the appropriate area (http://vidiot.com/images/LameXP-2.png).
(You can just provide the complete log, if you want to)
And how does one do that?

I can zip this particular disc for you to look at and place it on my server. Once you get it, I'll delete the file.

[LoRd_MuldeR]

Here is the png of the appropriate area (http://vidiot.com/images/LameXP-2.png).

So, indeed, the actual splitting process fails, on those particular tracks. But I have no idea, why exactly one those files. Any why it doesn't happen for me...

And how does one do that?

In the console (log) window, select "Edit -> Select All" from the system menu, or just press Ctrl+A. Then, once all is selected, press Enter to copy it. Finally, paste anywhere you like.

I can zip this particular disc for you to look at and place it on my server. Once you get it, I'll delete the file.

I don't think the exact FLAC/WAVE file makes a difference. After all, the other split processes, on the exactly same input FLAC file, seem to succeed :confused:

[MrVideo]

So, indeed, the actual splitting process fails, on those particular tracks. But I have no idea, why exactly one those files. Any why it doesn't happen for me...
But, might it happen for you with the actual flac file?
In the console window, select "Edit -> Select All" from the system menu, or just press Ctrl+A. Then, once all is selected, press Enter to copy it. Finally, paste anywhere you like.
D'Oh!
I don't think the exact FLAC/WAVE file makes a difference. After all, the other split processes, on the exactly same input FLAC file, seem to succeed :confused:
It doesn't hurt to try.

[MrVideo]

Just for grins, I installed the NCH switch program to convert the complete flac file to a single wav file.

I then edited a copy of the cue file and change the file to be imported to the wav file.

I imported that and it was even worse. Tracks 4-7, 10 & 18 failed. Not only that, the files that were extracted are garbage. The input wav file was fine, as I checked it out in the audio editing program.

[LoRd_MuldeR]

https://i.imgur.com/ftYXxWf.png

...try with this version:
http://www.mediafire.com/file/a1e9e58gyqy1qgq/LameXP-ALPHA.2020-04-18.Release-Static.Build-2257.zip

(Again we need the log output, but this special build should create more detailed logging)

I imported that and it was even worse. Tracks 4-7, 10 & 18 failed. Not only that, the files that were extracted are garbage. The input wav file was fine, as I checked it out in the audio editing program.

Okay, that is weird. With those other CUE files, which did not have any "skipped" files, you never encountered any "garbage" in the extract files? (did you check that?)

[MrVideo]

https://i.imgur.com/ftYXxWf.png

...try with this version:
http://www.mediafire.com/file/a1e9e58gyqy1qgq/LameXP-ALPHA.2020-04-18.Release-Static.Build-2257.zip

(Again we need the log output, but this special build should create more detailed logging)
I'd get you the log file, but the scroll buffer is too small. All I can get is part of track 19, thru to the end. I need to be able to see track 17, as track 18 (in this case) is what gets dropped. Is there any way you can output to a text file? Dropping it in the same location where the temporary WAV files are placed? I can then zip that and upload it.
Okay, that is weird. With those other CUE files, which did not have any "skipped" files, you never encountered any "garbage" in the extract files? (did you check that?)
I found the issue. I use an old program call CoolEdit200 to quickly edit WAV files. Something in the WAV file results in the program thinking that the file is hours long. In one case 3:22:53. After the song completes, extremely short snippets are repeated to fill the screen.

If I load the WAV file into Adobe Audition, it is displayed correctly. I then do a save-as to overwrite the file, so nothing is changed, except header info. Then CoolEdit2000 loads and displays the WAV file correctly. I do not know exactly what you are writing in the WAV files, but CoolEd2000 doesn't like them. Audition writes a file that is more compatible.

[LoRd_MuldeR]

I'd get you the log file, but the scroll buffer is too small. All I can get is part of track 19, thru to the end. I need to be able to see track 17, as track 18 (in this case) is what gets dropped. Is there any way you can output to a text file? Dropping it in the same location where the temporary WAV files are placed? I can then zip that and upload it.

You could try increasing the screen buffer size, at "Properties -> Layout" of the console window, before you start the import:
https://i.imgur.com/3ugV7XD.png

[MrVideo]

You could try increasing the screen buffer size, at "Properties -> Layout" of the console window, before you start the import:
Missed that one. I had set a different one.

I think I found the reason that CoolEdit2000 has issues:
> SoX: "C:\DOCUME~1\VIDIOT~1.SAT\LOCALS~1\Temp\01fd80f94964d022\lxp_sox.exe WARN
wav: Length in output .wav header will be wrong since can't seek to fix it"
I guess CoolEdit 2000 has issues with that, but Audition and the flac encoder do not.

As for why it fails, it seems as though sox can't write to the output file:
> SoX: "C:\DOCUME~1\VIDIOT~1.SAT\LOCALS~1\Temp\01fd80f94964d022\lxp_sox.exe FAIL
formats: can't open output file `F:\Simon_And_Garfunkel-Discography-FLAC\Compilation\
1997. Simon & Garfunkel - Old Friends (Columbia-Legacy 489447 2, Austria)\
Disc 2\Simon & Garfunkel - Old Friends [Disc 2] (4)\
[18] Simon & Garfunkel - Old Friends [Disc 2] - You Don't Know Where Your Interest Lies.wav':
No such file or directory"
(Output line split for easier reading.)

[LoRd_MuldeR]

As for why it fails, it seems as though sox can't write to the output file:

Indeed, for some reason, in case of Track #18, SoX was unable to open (create) the output file:
https://gist.github.com/lordmulder/a8651cb23ece04a9c3825211a974d72a

With a length of 269 characters, this path happens to be just a few characters longer than the traditional MAX_PATH limit of Windows, which is 260 characters :scared:

There are ways around that limit, on modern versions of Windows, but many applications still use/assume a fixed limit of 260 characters.

So, could you please try with a different output folder, for example "F:\Tracks\Simon & Garfunkel - Old Friends" instead of the longish "F:\Simon_And_Garfunkel-Discography-FLAC\Compilation\1997. Simon & Garfunkel - Old Friends (Columbia-Legacy 489447 2, Austria)\Disc 2" and see whether that solves the issue?

I think I found the reason that CoolEdit2000 has issues:

The WAVE file format is based on RIFF. And, in a RIFF file, each chunk (data element) starts with a header containing a "type" and a "length" field.

Now, when writing out a WAVE file, the total amount of samples that are going to be written is usually not known to the WAVE writer beforehand. So, the standard approach is this: At first, write a dummy "length" value into the chunk header; then keep on writing the actual audio data; and, a the very end, when we know the actual size of the data that was written, seek back to the beginning of the chuck an patch in the correct "length" value into the header.

For some unknown reason, it appears that SoX was unable to seek back in the file and thus was unable to patch in the correct "length" value :confused:

[MrVideo]

Sorry for the delay.
Indeed, for some reason, in case of Track #18, SoX was unable to open (create) the output file:
https://gist.github.com/lordmulder/a8651cb23ece04a9c3825211a974d72a

With a length of 269 characters, this path happens to be just a few characters longer than the traditional MAX_PATH limit of Windows, which is 260 characters :scared:
I was beginning to wonder if I hit the character buffer limit. I was going to try something, but sleep took over. :eek:
So, could you please try with a different output folder, for example "F:\Tracks\Simon & Garfunkel - Old Friends" instead of the longish "F:\Simon_And_Garfunkel-Discography-FLAC\Compilation\1997. Simon & Garfunkel - Old Friends (Columbia-Legacy 489447 2, Austria)\Disc 2" and see whether that solves the issue?
I created a simple S&G directory and copied over the three disc directories. That solved the problem. Thanks.

But, I ran into an issue trying to do the encoding. After scratching my head, I discovered that the 2257 version was using different registry entries (I hate the registry concept) and it was back to default settings: MP3 and output location. :(

I've since reinstalled the latest version and it is looking great.
For some unknown reason, it appears that SoX was unable to seek back in the file and thus was unable to patch in the correct "length" value :confused:
Is that a bug for the sox author(s) to figure out?

We're off to the races. :thanks:

[LoRd_MuldeR]

Sorry for the delay.

I was beginning to wonder if I hit the character buffer limit. I was going to try something, but sleep took over. :eek:

I created a simple S&G directory and copied over the three disc directories. That solved the problem. Thanks.

Good :)

But, I ran into an issue trying to do the encoding. After scratching my head, I discovered that the 2257 version was using different registry entries (I hate the registry concept) and it was back to default settings: MP3 and output location. :(

I've since reinstalled the latest version and it is looking great.

LameXP does not store settings in the registry, but in a simple INI file.

But, indeed, sometimes the settings stored in the INI file change in an incompatible way between LameXP releases, in which case each release uses a separate section in the INI file.

(I think the last time it happened was between v4.16 and v4.17, but not in v4.18)


Is that a bug for the sox author(s) to figure out?

We're off to the races. :thanks:

The last release of SoX dates back to 2015, so the project seems to be pretty much dead these days. Also, I don't know what's going on, since I don't see this warning on my side.

[MrVideo]

LameXP does not store settings in the registry, but in a simple INI file.
I went looking for the INI file in the program's location and did not see one, so I figured registry.
But, indeed, sometimes the settings stored in the INI file change in an incompatible way between LameXP releases, in which case each release uses a separate section in the INI file.
Ah, OK.
The last release of SoX dates back to 2015, so the project seems to be pretty much dead these days. Also, I don't know what's going on, since I don't see this warning on my side.
I would almost think a XP issue, but 2015 is in the XP era, so indeed strange.

It's kind-of a non-issue as I do not keep the WAV files that are created. If I need to edit the flac file, I'll just use Audition.

[LoRd_MuldeR]

I went looking for the INI file in the program's location and did not see one, so I figured registry.

The INI file is created in %LOCALAPPDATA% directory, as we cannot assume the install directory to be writable for normal users. On modern versions of Windows, "C:\Program Files" is not normally writable.

Also it allows each user to have its own separate configuration.

Having said that, if you rename the executable to "LameXP-Portable.exe", it will create the INI file in the same directory where the EXE file resides.

[huy]

1. fix read files subfolder
2. add title: size, type at tab source files.
See you again.

[LoRd_MuldeR]

1. fix read files subfolder
2. add title: size, type at tab source files.

Is this supposed be a riddle for us?

(Providing lots of detailed information is key to any support request)

[amayra]

i try to splitting some FLAC file from cue sheet but LameXP re-encode to wav file there any option to disable this to make LameXP splitting FLAC only

[LoRd_MuldeR]

i try to splitting some FLAC file from cue sheet but LameXP re-encode to wav file there any option to disable this to make LameXP splitting FLAC only

Nope, the CUE sheet importer creates temporary WAV files. But, of course, you can set output format to FLAC in the actual encoding step to get FLAC files in the end.

Even if we used SoX to split directly from FLAC to FLAC, I think internally SoX would first decode the input FLAC, then cut out the desired range of PCM samples, and finally re-encode to FLAC format. So, technically, that's really no different.

Anyway, specialized tools may be able to split a FLAC without re-encoding. Maybe have a look at CUETools (http://cue.tools/wiki/CUETools) for that specific use-case.

[MrVideo]

I asked this same thing several posts back in this thread. Because WAVe files and FLAC files are all lossless, there is no loss to audio quality. All you lose is a little time, very little time. Also, all of the FLAC metadata is transferred to the individual FLAC files.

If you are going to do work on more than one input FLAC file, import all of them first. Then recode them. Time will be saved when all of the new FLAC encodings are done at the same time.

[MrVideo]

Maybe have a look at CUETools (http://cue.tools/wiki/CUETools) for that specific use-case.
Unfortunately the author does not indicate one way or the other as to what the program does when the CUE file works with FLAC input files. Does it decode to a temporary WAVe file and then immediately recode to FLAC? Has the author figured out how to split the FLAC file and just add a new header, metadata info and the original FLAC data? Unknown. You'd have to go to its discussion forum and ask (if it hasn't been asked already).

[sloot]

Nos, ha rendelkezésre állna egy megfelelő CLI kódoló, akkor ezt is megvizsgálhatnám.

eac3to is the most popular command line tool for TrueHD Audio, DTS-HD MA sounds.

eac3to - audio conversion tool (https://forum.doom9.org/showthread.php?t=125966)

Please check if it is correct.
Thank You.

Best Regards.

[lvqcl]

Does it decode to a temporary WAVe file and then immediately recode to FLAC?
AFAIK yes.

[MrVideo]

I still prefer LameXP.

[MrVideo]

Enhancement suggestion: Add an option to remove the temporary WAV file that is created after a successful encoding.

[LoRd_MuldeR]

Enhancement suggestion: Add an option to remove the temporary WAV file that is created after a successful encoding.

Temporary files should always be removed.

In fact, each temporary WAV file is deleted as soon as the encoding processes finishes. Additionally, the whole "temp" directory (and thus all temporary files that still may persist) is removed, recursively, when LameXP is shutting down.

EDIT: You can look at the log (command-line switch "--console") to see whether there are any warnings about files that could not be removed for some reason.

[MrVideo]

The WAV files are not in a "temp" directory. They are in the final output directory, i.e., where the FLAC files are placed.

[LoRd_MuldeR]

The WAV files are not in a "temp" directory. They are in the final output directory, i.e., where the FLAC files are placed.

So, you are not talking about temporary WAV files created by LameXP, but some WAV files that you added as source files to be converted? :confused:

Maybe you consider these files as "temporary" in your worklfow, but for LameXP these are just normal source files.

Deleting the source file after (successful) conversion is not currently supported. There were requests for such an option before, but I'm still not sure I like the idea...

(This option would have great potential for damage, if the user accidentally enables it, or forgets to turn it off again)

[MrVideo]

So, you are not talking about temporary WAV files created by LameXP, but some WAV files that you added as source files to be converted? :confused:
Correct, sort-of. The source files were actually FLAC files read in by reading the CUE file, so that the single FLAC file can be split into the separate song FLAC files.
Maybe you consider these files as "temporary" in your worklfow, but for LameXP these are just normal source files.
Indeed, that I do.
Deleting the source file after (successful) conversion is not currently supported. There were requests for such an option before, but I'm still not sure I like the idea...

(This option would have great potential for damage, if the user accidentally enables it, or forgets to turn it off again)
Yep, I understand that. The key to this option is that it would only be in effect when the WAV files were created as the result of importing a FLAC cue file and the final output file type being other than a WAV (flac, mp3, etc.). In other words, as long as the imported files are NOT WAV, then the option would take effect.

[LoRd_MuldeR]

Yep, I understand that. The key to this option is that it would only be in effect when the WAV files were created as the result of importing a FLAC cue file and the final output file type being other than a WAV (flac, mp3, etc.). In other words, as long as the imported files are NOT WAV, then the option would take effect.

Well, the "problem" here is that, once those WAV files have been added to the source files list, they are just "normal" source files.

Of course, we cannot simply delete the source files (after conversion), just because they are WAV files, because WAV files can very well be added to the source file list in other ways - CUE import is not they only way.

So, yeah, to implement what you want, it would be necessary to carry some kind of additional "tag" along with each source file on the list which indicates how the particular source files was added to the list.

But, even then, it would be anything but clear whether the average user wants their source files to be deleted (after conversion), just because these files have been added to the source list via the CUE Sheet importer...

[MrVideo]

Hence an option that defaults to no. Yes, it would require an internal flag, of sorts, to keep track of this. It is a computer program after all. We can do anything with computer programs. :D

[LoRd_MuldeR]

Yes, it would require an internal flag, of sorts, to keep track of this. It is a computer program after all. We can do anything with computer programs. :D

Sure, it can be done, somehow. But I'm not sure the additional complexity to make this possible is worth it for a barely needed feature.

It's not done with the flag alone. If some files on the source files list do have a "self-destruct" flag set, while others don't, this needs to be indicated to the user in the GUI in some suitable way – because we don't want to have a "hidden" state in the application that will take the user by surprise. And, if so, then you'd probably want to also give the user a way to set or clear the "self-destruct" flag as needed...

[MrVideo]

That begs the question.... do users that take a single flac file and extract the individual tracks from the file keep the WAVE files or manually remove them? Obviously I do not keep them.

[SeeMoreDigital]

That begs the question.... do users that take a single flac file and extract the individual tracks from the file keep the WAVE files or manually remove them? Obviously I do not keep them.Remove them... Of-course ;)

[MrVideo]

Remove them... Of-course ;)
Hence my request for the automatic removal of the temporary WAV files.

[sloot]

Hi LoRd_MuldeR.

Thank you for making the no-splash option available.
Can you say something about post # 1674?

Regards.

[LoRd_MuldeR]

Can you say something about post # 1674?

Sorry, did not have time to look into this yet.

[MrVideo]

When encoding files, the status for filtering and encoding is not accurate. I've never seen them go above 20%. It varies as to what the peak percentage is. The only one that goes to 100% is decoding. Is there an issue as to why those two aren't displaying percentage correctly?

[LoRd_MuldeR]

When encoding files, the status for filtering and encoding is not accurate. I've never seen them go above 20%. It varies as to what the peak percentage is. The only one that goes to 100% is decoding. Is there an issue as to why those two aren't displaying percentage correctly?

Well, we "simply" parse the progress that is reported by the current decoder, filter or encoder process, and then we show it in the GUI.

So, every time the decoder, filter or encoder process prints a progress update to the stdout, the corresponding "worker" thread will parse the new progress value and send a signal the "main" (GUI) thread. GUI will then be updated accordingly.

If you think that, for a particular encoder or decoder, the progress is not parsed properly by LameXP, you will have to tell us which exact encoder or decoder is affected. In that case, you should first check the progress updates that are actually printed to the stdout by the affected encoder or decoder (e.g. by running the affected encoder or decoder in the terminal) and compare that to the progress that is displayed in LameXP.

If and only if LameXP is "missing" progress updates that actually have been printed by the encoder or decoder process, we might by able to fix something on the LameXP side. Having said that, progress updates generally work smoothly for me:
http://www.mediafire.com/file/6vbmv2buolemki3/encode_progress.mkv/file

Last but not least: Be aware that, for short files, the process will complete quickly. So there simply may not be a large number of progress update before the process completes – in which case it may seem like the progress just "jumps" to 100%.

[MrVideo]

If you think that, for a particular encoder or decoder, the progress is not parsed properly by LameXP, you will have to tell us which exact encoder or decoder is affected. In that case, you should first check the progress updates that are actually printed to the stdout by the affected encoder or decoder (e.g. by running the affected encoder or decoder in the terminal) and compare that to the progress that is displayed in LameXP.
Just to make things clear as to what I am doing, I'll repost it here: I'm taking flac files that contain multiple tracks and spliting them into separate flac tracks. So, the steps are create the WAV files. Then encode, which consists of decoding (what I do not know, since the WAV files are already there), filtering (normalizing the volume) and then encoding with the flac encoder.

The decoder does show all the way to 100%. The filter and encoder barely get above 0%. At most I've seen the encoder get to is 22% and these were files that took minutes to filter/encode. I'd run them on the command line, but in order to compare apples to apples, I'd have to know what the command line options are that you use. The console output doesn't supply that information.
If and only if LameXP is "missing" progress updates that actually have been printed by the encoder or decoder process, we might by able to fix something on the LameXP side. Having said that, progress updates generally work smoothly for me:
http://www.mediafire.com/file/6vbmv2buolemki3/encode_progress.mkv/file
No idea what encoder you were using and you weren't doing any filtering.

[LoRd_MuldeR]

Then encode, which consists of decoding (what I do not know, since the WAV files are already there), filtering (normalizing the volume) and then encoding with the flac encoder.

The decoder does show all the way to 100%.

The "decoder" for WAV files is a simple file copy. This is necessary to avoid modifications of the original file when the filter is applied (some filters work "in-place"). This step is simply skipped, if no filters are to be applied.

File copy does not invoke a separate process. We use CopyFileExW() to copy the WAV file. And we install a LPPROGRESS_ROUTINE callback to monitor the progress of the copy operation.

It is very possible that copying the file finishes so quickly that there is not much time to actually see any "intermediate" progress updates. So, in that case, it would effectively just "jump" to 100% very quickly.

Anyway, we can only update the progress displayed in the GUI when Windows actually invokes the supplied LPPROGRESS_ROUTINE callback. There is nothing else we could do on our side, I think.

The filter and encoder barely get above 0%. At most I've seen the encoder get to is 22% and these were files that took minutes to filter/encode. I'd run them on the command line, but in order to compare apples to apples, I'd have to know what the command line options are that you use. The console output doesn't supply that information.

We can only update that progress shown in the GUI when the filter process (e.g. SoX) actually reports any progress update.

As explained before, the one and only case in which things could possibly be improved on the LameXP side would be if any progress updates actually written out by the filter process (e.g. SoX) were "missed" or parsed wrongly by LameXP.

You can see the full command-line that LameXP invokes in the log, as always (just double-click an item after it has finished). Either that, or just use a tool like Process Monitor (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon).

No idea what encoder you were using and you weren't doing any filtering.

I was converting AAC (MP4) to MP3 with normalization filter enabled, in order to show you that the progress is displayed smoothly for the AAC decoder (FAAD), as well as the normalization filterer (SoX) and the MP3 encoder (LAME).

If you look at the video more carefully, you will see that the "filter" progress smoothly goes up from 0% to 100%. You can best see this with Track #1, which is the longest – it still completes pretty fast, so may want to step frame-by-frame.

[LoRd_MuldeR]

Here is new TEST build with some additional debug outputs in WAV decoder and Normalization filter:
http://www.mediafire.com/file/ax0bcnmdrm2z7dd/LameXP-TEST.2020-06-14.zip/file

Looks all good to me, though, when converting a WAV file with the Normalization filter (SoX) enabled:
https://pastebin.com/tinPicAd

(Only "anomaly" we can see here is that SoX reports 100% several times in a row, after reaching 100% for the first time. That is probably because SoX only reports the percentage of the input file that has been read thus far, not the percentage of the output file that has been written. So there probably will be some extra delay at the end of the normalization process, when flushing that pending data that is still buffered inside SoX)

[LoRd_MuldeR]

LameXP v4.19 Alpha-5

Changes between v4.18 and v4.19 [unreleased]
* Updated Monkey's Audio binary to v5.28 (2020-04-02), compiled with ICL 19.1 and MSVC 14.16
* Updated MediaInfo to v20.03 (2020-04-03), compiled with ICL 19.1 and MSVC 14.16
* Updated cURL to v7.69.1 (2020-03-11), with libcurl v7.69.1 and OpenSSL v1.1.0k
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startup

[LoRd_MuldeR]

LameXP v4.19 Alpha-6

Changes between v4.18 and v4.19 [unreleased]
* Updated Monkey's Audio binary to v5.28 (2020-04-02), compiled with ICL 19.1 and MSVC 14.16
* Updated mpg123 decoder to v1.26.2 (2020-07-05), compiled with GCC 10.1.0
* Updated MediaInfo to v20.03 (2020-04-03), compiled with ICL 19.1 and MSVC 14.16
* Updated cURL to v7.71.1 (2020-07-01), with libcurl v7.71.1 and OpenSSL v1.1.1g
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startup

[digitaltoast]

I installed the latest version this morning from the link above. It says:
"This demo (pre-release) version of LameXP has expired at 2020-08-11"

When I do "check for updates" I get a windows which says:
"No new updates. Currently installed Build 2274. Latest available: Build 2274".

Thank you for this great software and I look forward to trying the latest version!

[LoRd_MuldeR]

I installed the latest version this morning from the link above. It says:
"This demo (pre-release) version of LameXP has expired at 2020-08-11"

When I do "check for updates" I get a windows which says:
"No new updates. Currently installed Build 2274. Latest available: Build 2274".

Thank you for this great software and I look forward to trying the latest version!

Sorry about that. Should be fixed by now!

[LoRd_MuldeR]

LameXP v4.19 Alpha-7

Changes between v4.18 and v4.19 [unreleased]
* Updated Monkey's Audio binary to v5.28 (2020-04-02), compiled with ICL 19.1 and MSVC 14.16
* Updated mpg123 decoder to v1.26.2 (2020-07-05), compiled with GCC 10.1.0
* Updated MediaInfo to v20.03 (2020-04-03), compiled with ICL 19.1 and MSVC 14.16
* Updated cURL to v7.71.1 (2020-07-01), with libcurl v7.71.1 and OpenSSL v1.1.1g
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startup

[digitaltoast]

Great - thank you, new version works perfectly :)

[LoRd_MuldeR]

LameXP v4.19 Beta-2
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2020-09-05/LameXP-BETA.2020-09-05.Release-Static.Build-2278.exe/download

Changes between v4.18 and v4.19 [unreleased]
* Updated Vorbis encoder to OggEnc v2.88 (2020-07-07), using libvorbis v1.3.7 with aoTuV beta-6.03
* Updated Monkey's Audio binary to v5.54 (2020-08-24), compiled with ICL 19.1 and MSVC 15.9
* Updated mpg123 decoder to v1.26.3 (2020-07-16), compiled with GCC 10.1.0
* Updated MediaInfo to v20.08 (2020-08-11), compiled with ICL 19.1 and MSVC 15.9
* Updated cURL to v7.72.0 (2020-08-19), with libcurl v7.72.0 and OpenSSL v1.1.1g
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startup

[tormento]

LameXP v4.19 Beta-2
Couple of days the service is unavailable on downloading.

Strange enough, only one mirror has the download file.

Can you please provide a mirror? Binary expired here :scared:

[manolito]

SourceForge downloading can be a bit unreliable...

What always works here is to click on "Problems Downloading?" and then choose the "Direct Link". Just checked for the latest Beta-2, no problems.

[LoRd_MuldeR]

Couple of days the service is unavailable on downloading.

Strange enough, only one mirror has the download file.

Can you please provide a mirror? Binary expired here :scared:

Just checked, and all of the 16 update mirrors seem to be up and synchronized, so you should always be able to get the latest version via "auto-update" function:
https://pastebin.com/6vhtLuZi

As far as problems with SourceForge.net downloads are concerned, there is not much I can do about this, but I just downloaded the latest version from SourceForge.net without any problem.

[LoRd_MuldeR]

LameXP v4.19 Beta-3
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2020-09-21/LameXP-BETA.2020-09-21.Release-Static.Build-2280.exe/download

Changes between v4.18 and v4.19 [unreleased]
* Updated LAME encoder to v3.100.1-SVN (2020-08-25), compiled with ICL 19.1 and MSVC 15.9
* Updated Vorbis encoder to OggEnc v2.88 (2020-07-07), using libvorbis v1.3.7 with aoTuV beta-6.03
* Updated Monkey's Audio binary to v5.54 (2020-08-24), compiled with ICL 19.1 and MSVC 15.9
* Updated mpg123 decoder to v1.26.3 (2020-07-16), compiled with GCC 10.1.0
* Updated MediaInfo to v20.08 (2020-08-11), compiled with ICL 19.1 and MSVC 15.9
* Updated cURL to v7.72.0 (2020-08-19), with libcurl v7.72.0 and OpenSSL v1.1.1g
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startupLAME v3.100.1 Release
This is a point release that includes NO changes to the encoding libraries.
This release replaces the previous mpglib decoding library with the libmpg123 decoding library.

[MrVideo]

I notice while starting the program on my XP-32 box, it warns that dwnapi.dll is missing. Doing a little bit of research, I find out that its use starts with Vista. OK, but the strange part is that versions for XP-32 can be found and downloaded.

Is dwmapi really needed and what is it used for with regards to LameXP? I'm guessing that it isn't really important, since the program runs just fine without it.

[LoRd_MuldeR]

Some Windows API functions are only available in newer Windows versions. If we linked these functions statically, then the executable would no longer be able to run on "old" Windows versions.

The workaround is to import these "optional" functions dynamically, at runtime, via LoadLibrary() and GetProcAddress(). This way, we can use the new API functions where available, but still continue without them otherwise.

Specifically, the DWM (Desktop Window Manager) (https://docs.microsoft.com/en-us/windows/win32/dwm/dwm-overview) is only available in Windows Vista an later. LameXP uses DwmEnableBlurBehindWindow() from Dwmapi.dll to enable fancy "Aero" effects on support OS versions.

https://i.imgur.com/fhguMGT.png

[MrVideo]

Thanks for the update. Certainly doesn't bother me that blur effects are missing.

[MrVideo]

Slight problem... the beta has expired. I know, it keeps working. That is why it is slight.

Another slight problem... when trying to check for a new version, the beta says that my internet connection is broken. It isn't.

[LoRd_MuldeR]

Another slight problem... when trying to check for a new version, the beta says that my internet connection is broken. It isn't.

Not quite sure. Nothing about the update check should have changed recently :confused:

Can you can press F11 in the update window to show the log?

[MrVideo]

Here is the result:
Checking your Internet connection...

Connecting to host: www.ebay.com

ERROR: Terminated with unknown code -1073741515

Connecting to host: www.gnu.org

ERROR: Terminated with unknown code -1073741515

Connecting to host: bandcamp.com

ERROR: Terminated with unknown code -1073741515

Connecting to host: neocities.org

ERROR: Terminated with unknown code -1073741515

Connecting to host: www.avidemux.org

ERROR: Terminated with unknown code -1073741515
[...]
Connecting to host: support.proboards.com

ERROR: Terminated with unknown code -1073741515

Connecting to host: www.oxford.gov.uk

ERROR: Terminated with unknown code -1073741515

Connecting to host: www.jd.com

ERROR: Terminated with unknown code -1073741515

Connecting to host: marknelson.us

ERROR: Terminated with unknown code -1073741515

Connecting to host: www.libav.org

ERROR: Terminated with unknown code -1073741515


Connectivity test has failed: Internet connection appears to be broken!
Just a subset of the list. All sites exit with the some code. I have no clue has to how you are trying to connected to these locations. A simple ping of 8.8.8.8 would be a great test.

[nevcairiel]

-1073741515 is C0000135, which means "DLL not found". Some component involved in the connection process is not present.

[LoRd_MuldeR]

Here is the result:
Checking your Internet connection...

Connecting to host: www.gnu.org

ERROR: Terminated with unknown code -1073741515-1073741515 is C0000135, which means "DLL not found". Some component involved in the connection process is not present.

Well, it would indicate that cURL process failed to start, apprently because of a missing DLL.

If I remember correctly, you are one of those diehard Windows XP users. Not that we should care at this point, but for me the cURL binary that ships with LameXP works fine on my Windows XP (with SP-3) VM:

https://i.imgur.com/Ln27iKyl.jpg (https://i.imgur.com/Ln27iKy.jpg)

You could try opening the "lxp_curl.exe" form the LameXP "temp" directory with Dependency Walker (https://www.dependencywalker.com/) and see if it reveals anything...

[danlock]

Something I've intended to mention for quite a while... (It seems to be cosmetic only (NOT? SEE EDIT!), but it is confusing nonetheless.)

When I transcode one or more files to (an) Opus file(s), regardless of the Quality / Bitrate setting on the Compression tab, if I set a different bitrate in the OpusEnc text entry box in the Custom Encoder Parameters portion of the Advanced Options tab), the resulting file's ENCODER_OPTIONS: tag contains an extra artifact from the Compression tab.

In this example, the Compression tab was set to ≈ 144 kbps and my custom parameter was --bitrate 150, which resulted in the following ENCODER_OPTIONS tag:

ENCODER_OPTIONS : --vbr --comp 10 --framesize 20 --bitrate 144 --bitrate 150

The resulting file is the same as if the setting from the Compression tab were not present; the file is identical to one encoded with --bitrate 150. Either the second --bitrate option supersedes the first one on the command line, the setting from the tab is being inserted into the tag prior to the custom setting, or both.

I guess it's NOT cosmetic only (Edit #2: my mistake... it is only cosmetic, as LoRd_MuldeR reminded me (below)):

I just re-encoded the same file with a higher bitrate on the Compression tab (≈160) and got a larger file (tag says ENCODER_OPTIONS : --vbr --comp 10 --framesize 20 --bitrate 160 --bitrate 150), which remained larger/160kbps when I changed to 12kbps and re-encoded (custom still set to 150, tag says ENCODER_OPTIONS : --vbr --comp 10 --framesize 20 --bitrate 12 --bitrate 150) , but removing the custom option completely gave me a tiny file with an overall (VBR/quality) bit rate of 12.5 kbps. The tag ends with --bitrate 12 as it should.

Over the years since the Compression tab's --bitrate=??? text has been visible in the ENCODER_OPTIONS tag prior to the custom value, I have noticed no other strange tagging issues when I've had settings on the "ordinary" tabs that differ from any custom options I have set. I haven't tested exhaustively.

I'm using the latest beta, but I've noticed the tagging issue for many, many months and versions.

-------------
I was in a hurry at the end when I posted this yesterday. I neglected to thank you for your help and response, LoRd_MuldeR. I'll insert it now (Sunday 06.December 2020) and in this message to avoid creating another message at the bottom of the thread. Thank you! :) ...and I was right the first time: it is only cosmetic. Thanks for pointing that out, too!

[LoRd_MuldeR]

Well, it is not under our control what exactly OpusEnc stores in the "ENCODER_OPTIONS" meta tag. That's an OpusEnc thing.

Anyways, it would appear that OpusEnc simply stores the "raw" (full) command-line, not just the effective encoder options. This explains why you will see "--bitrate" twice, iff you add "--bitrate" to the "Custom Encoder Parameters": LameXP already generates the "--bitrate" option for you, based on the selected bitrate, on the "Compression" tab. Consequently, if you add that option again, as a custom parameter, you'll end up with two times "--bitrate" in the command-line.

Furthermore, the general convention for conflicting command-line options is that the last one takes precedence. And that is exactly what OpusEnc seems to follow here ;)

[LoRd_MuldeR]

LameXP v4.19 RC-2
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2021-01-21/LameXP-RC2.2021-01-21.Release-Static.Build-2288.exe/download

Changes between v4.18 and v4.19 [unreleased]
* Updated LAME encoder to v3.100.1-SVN (2020-08-25), compiled with ICL 19.1 and MSVC 15.9
* Updated Vorbis encoder to OggEnc v2.88 (2020-07-07), using libvorbis v1.3.7 with aoTuV beta-6.03
* Updated Monkey's Audio binary to v5.54 (2020-08-24), compiled with ICL 19.1 and MSVC 15.9
* Updated mpg123 decoder to v1.26.3 (2020-07-16), compiled with GCC 10.1.0
* Updated MediaInfo to v20.08 (2020-08-11), compiled with ICL 19.1 and MSVC 15.9
* Updated cURL to v7.72.0 (2020-08-19), with libcurl v7.72.0 and OpenSSL v1.1.1g
* Added Bulgarian (български) translation, thanks to Симеон Илиянов Цветков <sicvetkov@uni-sofia.bg>
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startupLAME v3.100.1 Release
This is a point release that includes NO changes to the encoding libraries.
This release replaces the previous mpglib decoding library with the libmpg123 decoding library.

[MrVideo]

Sorry for the delay in responding. I got sidetracked.Well, it would indicate that cURL process failed to start, apprently because of a missing DLL.
I had to search the C: drive in order to find lxp_xurl. When I manually run it, it povides me with some help options. But, there was no failure.
If I remember correctly, you are one of those diehard Windows XP users. Not that we should care at this point, but for me the cURL binary that ships with LameXP works fine on my Windows XP (with SP-3) VM:
It is true, but I have moved some stuff over to Win7-64. LameXP is run from my XP box for logistical reasons.
You could try opening the "lxp_curl.exe" form the LameXP "temp" directory with Dependency Walker (https://www.dependencywalker.com/) and see if it reveals anything...
I have no idea what I am looking for in its output. But, it didn't complain about no DLLs not being found.

As a test, I did: lxp_curl -I --url http://forum.doom9.org and all went well. It displayed the http header.

Why not just ping 8.8.8.8? That IP isn't going away any time soon.

At this point, I don't think that curl is the issue.

Used the above 2288 build and still not able to determine if the internet is working.

[MrVideo]

I just noticed that when extracting flac tracks from a flac file, the directory that is created always has a " (2)" added to the name, even though it is the only directory there.

Oh wait, I see why it did it. If the flac file is named: Album.flac, it tries to create a working directory called: Album.flac. Obviously that is a conflict. The directory that contains the files is called: Album. So, why not make the working directory: Album. Then there won't be a conflict.

[LoRd_MuldeR]

I had to search the C: drive in order to find lxp_xurl. When I manually run it, it povides me with some help options. But, there was no failure.

Just go to the %TMP% directory. LameXP will create a sub-folder with a random name here on startup. The lxp_curl.exe you are looking for will be in there.

I have no idea what I am looking for in its output. But, it didn't complain about no DLLs not being found.

Watch out for a missing DLL file, or for a missing entry point in one of the required DLLs. For me all looks good on my Windows XP machine though:
https://imgur.com/a/7SyOy5j

(Note: Warning about delay-loaded DLLs can be ignored, because delay-loading is commonly used for optional dependencies)

As a test, I did: lxp_curl -I --url http://forum.doom9.org and all went well. It displayed the http header.

Then I don't understand what was the problem before :confused:

In your earlier post you said that cURL failed to run with error code -1073741515, aka 0xC0000135, aka STATUS_DLL_NOT_FOUND:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55

So that would have indicated that the cURL process could not be created because of a missing DLL.

If, however, you can start cURL from the command-line without problem, and if you are 100% sure that you were testing the same "lxp_curl.exe" file, then a missing DLL apparently is not the problem.

Why not just ping 8.8.8.8? That IP isn't going away any time soon.

Ping is a whole different thing than HTTP. While HTTP is based on TCP, the "ping" command is implemented via ICMP (https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol). Note that ICMP is neither based on TCP nor UDP, but is a "layer 3" protocol of its own.

Generally, a working "ping" does not guarantee that a HTTP/TCP connection will work too. At the same time, if a sever doesn't respond to "ping", it could still respond to HTTP/TCP. Many web-servers block ICMP for security reasons.

So, it is much more meaningful to test an actual HTTP/TCP connection than only "ping'ing" the server.

Furthermore, trying to connect to an IP address instead of a host name wouldn't test DNS resolution at all! So, we have to connect to an actual host name, in order to see whether DNS resolution is working properly.

Last but not least, testing just a single host name (server) would be unreliable, because it would introduce a single point of failure (https://en.wikipedia.org/wiki/Single_point_of_failure).

That's why we have a list of many "known" host names (160 at this time), and we consider the Internet connection to be "working" as soon as at least 5 out of those could be reached successfully.

I just noticed that when extracting flac tracks from a flac file, the directory that is created always has a " (2)" added to the name, even though it is the only directory there.

Oh wait, I see why it did it. If the flac file is named: Album.flac, it tries to create a working directory called: Album.flac. Obviously that is a conflict. The directory that contains the files is called: Album. So, why not make the working directory: Album. Then there won't be a conflict.

I assume you are talking about CUE sheet import here ;)

In fact, the default (suggested) name of the output folder is based on the file name of the .cue file that you are importing, not on the name of any of the Wave, FLAC or whatever file(s) that are referenced in the .cue file.

The suggested output folder name should contain a "…(n)" suffix, if and only if a file or directory of the name without that suffix already exists.

Is it possible that your .cue file was called something like "album.flac.cue" and therefore the suggested output folder name would be "album.flac", but a file named "album.flac" already existed?

[MrVideo]

Just go to the %TMP% directory. LameXP will create a sub-folder with a random name here on startup. The lxp_curl.exe you are looking for will be in there.
I use the cygwin terminal and it knows nothing about %TMP%. I just did a search of the program on te C: drive to find it.

An important piece of info was missing from your first response. I enbolded the text. You didn't tell me that. What I found on my system was created in June of 2020. It works.
Watch out for a missing DLL file, or for a missing entry point in one of the required DLLs. For me all looks good on my Windows XP machine though:
https://imgur.com/a/7SyOy5j
Yours looks a little different than mine.
In your earlier post you said that cURL failed to run with error code -1073741515, aka 0xC0000135, aka STATUS_DLL_NOT_FOUND:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55

So that would have indicated that the cURL process could not be created because of a missing DLL.

If, however, you can start cURL from the command-line without problem, and if you are 100% sure that you were testing the same "lxp_curl.exe" file, then a missing DLL apparently is not the problem.
Based on the new information about lxp_curl.exe, I first started lamexp and then looked for the program. I then found the "new" version and it indeed fails. The walker indicates that normaliz.dll is missing, which indeed it is. Was this DLL ever shipped with WinXP, or ever added with a patch? I'm at SP3. I found a site to get it, but I need to know the info about the one that you are running (they have several versions). The info line from the walker program will do.
Ping is a whole different thing than HTTP. While HTTP is based on TCP, the "ping" command is implemented via ICMP (https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol). Note that ICMP is neither based on TCP nor UDP, but is a "layer 3" protocol of its own.
'Tis very true.
Generally, a working "ping" does not guarantee that a HTTP/TCP connection will work too. At the same time, if a sever doesn't respond to "ping", it could still respond to HTTP/TCP. Many web-servers block ICMP for security reasons.
True, but google doesn't. I use it to see if my internet connection is alive or dead. If it doesn't work, nothing will.
Furthermore, trying to connect to an IP address instead of a host name wouldn't test DNS resolution at all! So, we have to connect to an actual host name, in order to see whether DNS resolution is working properly.
While that is true, the user would have discovered a DNS issue via other means, i.e., just by trying to go to any website via their browser. Odds are that a user would have found an issue with their LAN, or internet connection, long before running lamexp.
Last but not least, testing just a single host name (server) would be unreliable, because it would introduce a single point of failure (https://en.wikipedia.org/wiki/Single_point_of_failure).

That's why we have a list of many "known" host names (160 at this time), and we consider the Internet connection to be "working" as soon as at least 5 out of those could be reached successfully.
IMHO, doing this test is overkill, because of the very reason I mentioned above. Just go to your site to look for the update and if it doesn't work, report back to the user. At that point the user can troubleshoot their LAN/internet.
In fact, the default (suggested) name of the output folder is based on the file name of the .cue file that you are importing, not on the name of any of the Wave, FLAC or whatever file(s) that are referenced in the .cue file.

[quote]Is it possible that your .cue file was called something like "album.flac.cue" and therefore the suggested output folder name would be "album.flac", but a file named "album.flac" already existed?
In this case, that is indeed true. That is because there was an album.flac.cue and album.wave.cue file. Why there is a wave cue file is beyond me, size there are no wave files.

Suggestion... if this situation arises, how about adding a pop-up asking the user to enter a new directory name? That is because I end up having to go back and manually rename the directories. Easier to do it up front.

[LoRd_MuldeR]

Based on the new information about lxp_curl.exe, I first started lamexp and then looked for the program. I then found the "new" version and it indeed fails. The walker indicates that normaliz.dll is missing, which indeed it is. Was this DLL ever shipped with WinXP, or ever added with a patch? I'm at SP3. I found a site to get it, but I need to know the info about the one that you are running (they have several versions). The info line from the walker program will do.

I don't know. And because Windows XP went "end of life" so long ago, it is hard to find any information. On my Windows XP (SP-3) system it just worked ;)

The Microsoft site about the IdnToAscii() function, which is the only function cURL imports from "normaliz.dll", says:
Windows XP, Windows Server 2003:
The required header file and DLL are part of the Microsoft Internationalized Domain Name (IDN) Mitigation APIs, which are no longer available for download.

Apparently there used to be a redistributable installer, specifically for Windows XP. So you can try with this archived copy that I was able to dig up:
idndl.x86.exe (https://sourceforge.net/projects/lamexp/files/Miscellaneous/Redistributables/idndl.x86.exe/download)

(Vista and later apparently provide "normaliz.dll" out-of-the-box)

In this case, that is indeed true. That is because there was an album.flac.cue and album.wave.cue file. Why there is a wave cue file is beyond me, size there are no wave files.

Suggestion... if this situation arises, how about adding a pop-up asking the user to enter a new directory name? That is because I end up having to go back and manually rename the directories. Easier to do it up front.

I don't see why that would be needed. After all, we are talking about the suggested (default) name of the output directory.

If you don't like the default, you can always choose a different output directory of your liking – in the CUE Sheet import dialog – before you start the import/splitting process.

Hence, there should be no need to rename anything afterwards...

While that is true, the user would have discovered a DNS issue via other means, i.e., just by trying to go to any website via their browser. Odds are that a user would have found an issue with their LAN, or internet connection, long before running lamexp.

Well, this is not about what the user might be able to figure out. It is about how the application reliably detectes whether we have a "working" Internet connection or not.

Just go to your site to look for the update and if it doesn't work, report back to the user. At that point the user can troubleshoot their LAN/internet.

That's the point. If we weren't able to fetch the update info from our update mirror, we don't know whether it is because our update mirror is down, or because of a more general problem with the user's Internet connection.

Sure, we could simply throw a typical meaningless "Uh oh: Something went wrong!" error message and let the user figure out the specifics. But I think showing a somewhat more helpful error message is nice ;)

Furthermore, since this is already implemented, I don't see a reason to drop a better, already working solution in favor of an inferior one.

Most important: Dropping the Internet connection test would not solve your cURL issues at all, because a working cURL would still be required for the actual download of the update information. You wouldn't gain anything.

[danlock]

> I use the cygwin terminal and it knows nothing about %TMP%.
> I just did a search of the program on te C: drive to find it.

I think the applicable Windows environment variable is %temp% (which redirects to Windows' temporary directory)

... good luck :)

[MrVideo]

> I use the cygwin terminal and it knows nothing about %TMP%.
> I just did a search of the program on te C: drive to find it.

I think the applicable Windows environment variable is %temp% (which redirects to Windows' temporary directory)
Cygwin doesn't know it either.

[MrVideo]

I don't know. And because Windows XP went "end of life" so long ago, it is hard to find any information. On my Windows XP (SP-3) system it just worked ;)
Somehow you managed to get it on your system.:D
The Microsoft site about the IdnToAscii() function, which is the only function cURL imports from "normaliz.dll", says:

Apparently there used to be a redistributable installer, specifically for Windows XP. So you can try with this archived copy that I was able to dig up:
idndl.x86.exe (https://sourceforge.net/projects/lamexp/files/Miscellaneous/Redistributables/idndl.x86.exe/download)
That fixed it. Sometime after the June 2020 version of cURL you were using, the program got changed and started using normaliz.dll. You never stumbled on the issue because you already had that DLL on your system. Leave it to me to find that issue.
Most important: Dropping the Internet connection test would not solve your cURL issues at all, because a working cURL would still be required for the actual download of the update information. You wouldn't gain anything.
Well, that certainly makes the point moot.

Now we know what to do if this were to happen to anyone else. :D

Thanks for helping me find the issue.

BTW: I removed the other cURL directory from last year, so I won't get fooled again.

[MrVideo]

I don't see why that would be needed. After all, we are talking about the suggested (default) name of the output directory.

If you don't like the default, you can always choose a different output directory of your liking – in the CUE Sheet import dialog – before you start the import/splitting process.

Hence, there should be no need to rename anything afterwards...
Unfortunately, I do want the results placed in the source directory. Oh well.

[LoRd_MuldeR]

Somehow you managed to get it on your system.:D

It is included with IE7 or later, and probably many other applications. Actually, I was able to extract the required "idndl.x86.exe" redistributable from an old IE7 for Windows XP setup package.

Since, after a fresh install, I always update my system to the latest version with WSUS Offline Update (https://www.wsusoffline.net/), including the latest supported version of IE, that's probably how I got it.

That fixed it. Sometime after the June 2020 version of cURL you were using, the program got changed and started using normaliz.dll. You never stumbled on the issue because you already had that DLL on your system. Leave it to me to find that issue.

Okay. So I will include the "idndl.x86.exe" redistributable in the LameXP installer for now. Just to be sure.

Unfortunately, I do want the results placed in the source directory. Oh well.

No idea :confused:

After you have opened the CUE file to be imported but before you hit "Import Cue Sheet" simply click the "Browse" button (in the "Output directory" groupbox) and then choose whatever output directory you like. That's it.

[MrVideo]

It is included with IE7 or later, and probably many other applications. Actually, I was able to extract the required "idndl.x86.exe" redistributable from an old IE7 for Windows XP setup package.

Since, after a fresh install, I always update my system to the latest version with WSUS Offline Update (https://www.wsusoffline.net/), including the latest supported version of IE, that's probably how I got it.
I never updated IE7, as I do not use IE for any web browsing. All of my browsing is done on my Linux server using Opera and Vivaldi.
Okay. So I will include the "idndl.x86.exe" redistributable in the LameXP installer for now. Just to be sure.
Sounds like a great idea.

[LoRd_MuldeR]

I never updated IE7, as I do not use IE for any web browsing. All of my browsing is done on my Linux server using Opera and Vivaldi.

Keep in mind that many applications use embedded IE frames ;)

[LoRd_MuldeR]

LameXP v4.19 RC-3
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2021-02-18/LameXP-RC3.2021-02-18.Release-Static.Build-2294.exe/download

Changes between v4.18 and v4.19 [unreleased]
* Updated LAME encoder to v3.100.1-SVN (2020-08-25), compiled with ICL 19.1 and MSVC 15.9
* Updated Vorbis encoder to OggEnc v2.88 (2020-07-07), using libvorbis v1.3.7 with aoTuV beta-6.03
* Updated Monkey's Audio binary to v6.12 (2021-02-15), compiled with ICL 19.2 and MSVC 15.9
* Updated mpg123 decoder to v1.26.4 (2020-12-24), compiled with GCC 10.2.0
* Updated MediaInfo to v20.09 (2020-10-09), compiled with ICL 2021.1 and MSVC 15.9
* Updated cURL to v7.75.0 (2021-02-03), with libcurl v7.75.0 and OpenSSL v1.1.1i
* Added Bulgarian (български) translation, thanks to Симеон Илиянов Цветков <sicvetkov@uni-sofia.bg>
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startup
* Added a workaround for missing normaliz.dll to the installer (Windows XP only)

[MrVideo]

Keep in mind that many applications use embedded IE frames ;)
True. The only one that I know of that works just fine is VideoReDo. If there are others, there has never been a complaint (error). I guess I've been lucky.

[manolito]

Getting THIS again:
https://forum.doom9.org/showthread.php?p=1892386#post1892386

All I can do is repeat my request from this older post. I totally understand if you do not want your users to use alpha, beta or RC versions forever, but for stable versions this nagging is totally annoying and unnecessary.

Please...

[TTR]

Getting THIS again:
https://forum.doom9.org/showthread.php?p=1892386#post1892386

All I can do is repeat my request from this older post. I totally understand if you do not want your users to use alpha, beta or RC versions forever, but for stable versions this nagging is totally annoying and unnecessary.

Please...

Have to say I completely agree with this and made an account just to post this. I LOVE LameXP, but being bombarded to check for an upgrade where there isn't one is just silly, and the music that it plays when skipping the upgrade check is entirely unnecessary and doesn't mute when sounds are otherwise muted. I get "this program hasn't been updated in a year" notices constantly.

[Atak_Snajpera]

https://www.nirsoft.net/utils/run_as_date.html

[TTR]

https://www.nirsoft.net/utils/run_as_date.html

That seems like it would be a great workaround and I appreciate it, but I'm not having any luck with it. Still getting the "this version is over a year old" prompt. Thank you though!

[LoRd_MuldeR]

Have to say I completely agree with this and made an account just to post this. I LOVE LameXP, but being bombarded to check for an upgrade where there isn't one is just silly, and the music that it plays when skipping the upgrade check is entirely unnecessary and doesn't mute when sounds are otherwise muted. I get "this program hasn't been updated in a year" notices constantly.

Sorry for late replay. This has already been addressed for the upcoming release.

Until a new "stable" version is released, which will be very soon (hopefully), you can grab the latest "test" version here:
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2021-05-22/

Regards.

[jpsdr]

I've installed and tested the moment it was out the stable 4.18. I rarely use LameXP, but i wanted to use it now, and it crashed (it didn't at the time i've installed it)...
I've uninstalled the 4.18 and installed the beta 4.19, and when i start it, Kaspersky said that there is a virus trojan in \TEMP\xxxxx\lxp_curl.exe.

[LoRd_MuldeR]

I've installed and tested the moment it was out the stable 4.18. I rarely use LameXP, but i wanted to use it now, and it crashed (it didn't at the time i've installed it)...
Well, without more detailed information, it is impossible to analyze the problem.

But I can tell you that I regularly test on different systems, ranging from latest Windows 10 running on my Core-i7 machine to Windows XP SP-3 running on a Pentium II machine, and haven't encountered any crashes.

BTW: If you use any so-called "anti-virus" software (other than Microsoft Defender) I suggest tying to disabling it and then try again. Buggy "anti-virus" software is a common cause of "mysterious" crashes.

I've uninstalled the 4.18 and installed the beta 4.19, and when i start it, Kaspersky said that there is a virus trojan in \TEMP\xxxxx\lxp_curl.exe.
https://www.heise.de/select/ct/2021/12/2031014511239568241

(Honestly, at this point, I won't explain, for the umpteenth time, what a "False Positive" is and who you have to report it to if you want it fixed)

[K4sum1]

The program opens, but gives me you must be running Windows 8 or higher, on Windows 8.

Can you remove the error entirely? If the program doesn't work on 7 or older, it just doesn't work, there doesn't need to be an artificial limit to what it runs on.

[LoRd_MuldeR]

The program opens, but gives me you must be running Windows 8 or higher, on Windows 8.

Can you remove the error entirely? If the program doesn't work on 7 or older, it just doesn't work, there doesn't need to be an artificial limit to what it runs on.

LameXP runs on Windows XP or later, up to and including Windows 10. I frequently verify that the program runs on my Windows XP, Windows 8.1 and Windows 10 machines. So I'm a bit confused here :confused:

What exact version of Windows you are running on and what exact version of LameXP you are trying to use?

Do you get that message from the LameXP "main" program or from the installer? A screenshot and some more details may be helpful. Can you run LameXP withe option '--console' and post the output?

[K4sum1]

LameXP runs on Windows XP or later, up to and including Windows 10. I frequently verify that the program runs on my Windows XP, Windows 8.1 and Windows 10 machines. So I'm a bit confused here :confused:

What exact version of Windows you are running on and what exact version of LameXP you are trying to use?

Do you get that message from the LameXP "main" program or from the installer? A screenshot and some more details may be helpful. Can you run LameXP withe option '--console' and post the output?
Sorry for the late response, I never got a notification email.

First screenshot is running normally, second screenshot is running with --console.

I kinda forgot a slight detail in the first post (since I had to wait 5 days before being able to post), but you can see it in the screenshots.

https://i.imgur.com/OO7uAJR.jpg

[LoRd_MuldeR]

Apparently you are using Windows 8.0, rather than Windows 8.1.

Window 8.0 has reached end of life in 2016, i.e. 5 years ago. Just update to Windows 8.1, which is essentially a Service Pack to Windows 8 and will be supported with security fixes by Microsoft until 2023.

At this point, I won't put any effort into testing or supporting Windows 8.0. The same applies to Windows 7 without SP-1, or Windows XP without SP-3.

(BTW: Please don't post ultra-large screenshots as attachments. It breaks the layout.)

Is There a Difference Between 8 and 8.1?

The answer is no, not really. Windows 8.1 is considered a service pack for Windows 8. This means Windows 8.1 is a part of Windows 8 and is included in that life cycle.

[K4sum1]

Apparently you are using Windows 8.0, rather than Windows 8.1.

Window 8.0 has reached end of life in 2016, i.e. 5 years ago. Just update to Windows 8.1, which is essentially a Service Pack to Windows 8 and will be supported with security fixes by Microsoft until 2023.

At this point, I won't put any effort into testing or supporting Windows 8.0. The same applies to Windows 7 without SP-1, or Windows XP without SP-3.

(BTW: Please don't post ultra-large screenshots as attachments. It breaks the layout.)

8.0 is better than 7 and 8.1 in various ways. It has a better DWM than 7, but without the activation system of 8.1. It can be easily modded to use the 7 explorer, while 8.1 has buggy start menu replacements. It has the better performance of 8.x without the telemetry updates of 8.1.

Also, about support, 8.0 Embedded gets support until 2023 as well, and 8.0 embedded updates work on regular 8.0.

[LoRd_MuldeR]

8.0 is better than 7 and 8.1 in various ways. It has a better DWM than 7, but without the activation system of 8.1. It can be easily modded to use the 7 explorer, while 8.1 has buggy start menu replacements. It has the better performance of 8.x without the telemetry updates of 8.1.

Also, about support, 8.0 Embedded gets support until 2023 as well, and 8.0 embedded updates work on regular 8.0.

Fell free to use whatever outdated and end-of-live operating system you like – it is you who has to live with the implications. I could go on to elaborate on how irresponsibly it is to use an end-of-live operating system. But I know that trying to "proselytize" notorious update refusers is a totally pointless endeavor. So, do what you want, but do not expect software developers to care about such super-exotic configuration. Windows 8.x generally is a lost cause, because it never gained much popularity and was quickly superseded by Windows 10. But Windows 8.0 without the Windows 8.1 service pack in particular is such a niche configuration that it's not worth bothering...

(BTW: You are the first person to ever try running this software on Windows 8.0, and report back. I think that says it all.)

[shades]

Dear LoRd_MuldeR
Latest nightly build LameXP-RC10.2021-06-27.Release-Static.Build-2316 seems to be broken on extraction of the file wvunpack.exe

Extracting file: wvunpack.x64-avx.exe -> wvunpack.exe
Failedto open file on first attempt, retrying...
QFile::remove: Empty or null file name
BaseTask exception error:
File 'lxp_curl.exe' could not be locked

GURU MEDITATION !!! <- (NICE! :-D AMIGA throwback?? lol )

[LoRd_MuldeR]

Dear LoRd_MuldeR
Latest nightly build LameXP-RC10.2021-06-27.Release-Static.Build-2316 seems to be broken on extraction of the file wvunpack.exe

Extracting file: wvunpack.x64-avx.exe -> wvunpack.exe
Failedto open file on first attempt, retrying...
QFile::remove: Empty or null file name
BaseTask exception error:
File 'lxp_curl.exe' could not be locked

GURU MEDITATION !!! <- (NICE! :-D AMIGA throwback?? lol )

Probably yet another case of "anti-virus" software gone nuts :rolleyes: :D

If you run any "anti-virus" software, please turn it off (or, even better: uninstall) in order to confirm that the root cause of the problem indeed is a buggy "anti-virus" software. Then report the problem to then vendor.

(Should the problem persist after any "anti-virus" software has been eradicated from the system, then I may investigate further)

[shades]

Probably yet another case of "anti-virus" software gone nuts :rolleyes: :D

If you run any "anti-virus" software, please turn it off (or, even better: uninstall) in order to confirm that the root cause of the problem indeed is a buggy "anti-virus" software. Then report the problem to then vendor.

(Should the problem persist after any "anti-virus" software has been eradicated from the system, then I may investigate further)

You are of course, correct.
Rotten Windows 10 simple pattern matching crap.
I placed an exception for the entire folder for MuldeR and it's frikken fine as.

thanks for the time in answering. :)

[danlock]

(title)

Details: @LoRd_MuldeR Do you intend to support .webp album covers in LameXP (so they will be transferred from the source to the destination file(s) for supported formats/containers)? If so, do you have a timeline or a version number in mind when that will be implemented?

Thank you very much! :thanks:

[LoRd_MuldeR]

Details: @LoRd_MuldeR Do you intend to support .webp album covers in LameXP (so they will be transferred from the source to the destination file(s) for supported formats/containers)? If so, do you have a timeline or a version number in mind when that will be implemented?

Not currently planned. There are many open questions regarding WebP:
Does Qt support the WebP format? I think Qt 4, which LameXP is currently based on, does not. Probably current Qt 5 does. But then, porting LameXP to Qt 5 will be a big project for the future :o
Do the various audio formats that we support in LameXP support the WebP format in their meta data? For example, MP3 embeds meta data in the form of ID3 tags. And, to the best of my knowledge, ID3v2 "officially" only supports JPEG and PNG. Which is obvious, because at the time that ID3v2 was created WebP didn't even exist! And that's only MP3. What about all the other formats? :confused:
Even if some of the audio formats that we support actually do support WebP in their meta data, do the encoders that we use support WebP as input? What do we do with the other formats? :(

[danlock]

:goodpost:
Not currently planned.

Understandable. Thank you again!

There are many open questions regarding WebP:
Does Qt support the WebP format? I think Qt 4, which LameXP is currently based on, does not. Probably current Qt 5 does. But then, porting LameXP to Qt 5 will be a big project for the future :o
Do the various audio formats that we support in LameXP support the WebP format in their meta data? For example, MP3 embeds meta data in the form of ID3 tags. And, to the best of my knowledge, ID3v2 "officially" only supports JPEG and PNG. Which is obvious, because at the time that ID3v2 was created WebP didn't even exist! And that's only MP3. What about all the other formats? :confused:
Even if some of the audio formats that we support actually do support WebP in their meta data, do the encoders that we use support WebP as input? What do we do with the other formats? :(

Foobar 2000 can read .webp files in metadata (and add or remove .webp files as metadata). That was first implemented by pointing Fb2k to an external file, and later added internally (September 2000). That's a program which was coded from the ground up to support plugins and other features, though, and Peter can alter his code base or plugins to add/remove support for different things anytime. It's possible other players/encoders can read .webp metadata as well, but I can't think of any. I presumed any other relatively-decent player would discard the .webp image data as extraneous. A poorly-coded player, on the other hand, would see the "extra" data and crash or claim the file is bad, but (come to think of it) since metadata exists as a separate, resizable part of the file (whether as part of the audio file or in an external tag file), it probably just wouldn't be displayed.

As small as lossy .webp (and the next version, .webp2) files are compared to most other image formats with similar quality, it's a space savings to use .webp format in audio files (lossless .webp files obviously don't compress as much). For maximum compatibility and even more space, I should probably just use an external image in the directory and put only textual metadata in the files.

Support in QT seems to be the biggest hurdle. I had not considered that. Thanks for reminding me of LameXP's usage of QT! :)

Well, for the purposes of this forum and LameXP, the future is approaching at a fixed speed. End users like me will probably learn of support for any new formats whenever any porting to a newer version of QT occurs, since the tagging is typically handled by the external components for which LameXP provides the interface. And those decoder/encoder combinations that don't support .webp would output a file that doesn't contain the image, of course, like they already do.

Something will change when those included external decoders work for newer metadata or LameXP itself can copy metadata in (.webp/etc.) whatever formats are present in the file, in the future, whenever it happens.

Speaking of time, I've allowed far too much of it to march past me while I typed this message! (Muss los!)

[LoRd_MuldeR]

LameXP v4.19 has been released :)
https://github.com/lordmulder/LameXP/releases/latest

Changes between v4.18 and v4.19 [2021-08-29]:
* Updated LAME encoder to v3.100.1-SVN (2020-08-25), compiled with ICL 19.1 and MSVC 15.9
* Updated Vorbis encoder to OggEnc v2.88 (2020-07-07), using libvorbis v1.3.7 with aoTuV beta-6.03
* Updated Monkey's Audio binary to v6.29 (2021-05-25), compiled with ICL 19.2 and MSVC 15.9
* Updated mpg123 decoder to v1.26.4 (2020-12-24), compiled with GCC 10.2.0
* Updated MediaInfo to v21.03 (2021-03-26), compiled with ICL 2021.2 and MSVC 15.9
* Updated cURL to v7.77.0 (2021-05-26), with libcurl v7.77.0 and OpenSSL v1.1.1k
* Updated the Windows SDK version used for release builds (Visual Studio 2017) to 10.0.14393.0
* Added Bulgarian (български) translation, thanks to Симеон Илиянов Цветков <sicvetkov@uni-sofia.bg>
* Added command-line switch --no-splash, which can be used to hide the "splash" screen at startup
* Added a workaround for missing normaliz.dll to the installer (Windows XP only)
* GnuPG has been replaced by CodeSign (https://bitbucket.org/muldersoft/codesign/src/master/) verification tool for checking the auto-update signatures
* Updated language files (big thank-you to all contributors !!!)

[SeeMoreDigital]

Hi LoRd_MuldeR,

I've just tried installing the new release but for some reason Windows 10 Home (Version: 21H1, OS Build: 19043.1165) reports the following: -

https://i.ibb.co/2gnvjsH/Lame-XP-warning.jpg

https://i.ibb.co/vjfhjnR/Capture.jpg

[LoRd_MuldeR]

As a long term member, I probably don't have to explain to you what a FALSE POSITIVE is and who you need to report the problem in their software to, if you want a chance for this to be fixed ;)

Also, I probably don't have to explain that even though cURL (https://curl.se/) could be abused by "attackers" to do evil things (like pretty much any non-trivial program can be abused!) it still is a perfectly legitimate software that must not be blocked :o

See also:
http://lamexp.sourceforge.net/doc/Manual.html#anti-virus-notes

(Note: Since we have been through this a zillion of times, that is as much as I'm going to say about the topic)

[jpsdr]

For me, Kaspersky didn't like lxp_curl.exe created in temp directory when lamexp is running. Contacted them, confirmed as false positive, will be fixed very shortly in their database. I had to do the same exact same process for the exact same file with previous lamexp version, and probably will with next version... :(
But lamexp is very good at trigging false positive... ;)

[manolito]

Sorry for late replay. This has already been addressed for the upcoming release.


Thanks for the new version :D

The new behavior after starting the software when it is more than 1 yeaur old is very welcome...

[K4sum1]

Is there no way to encode in ALAC?

[SeeMoreDigital]

Is there no way to encode in ALAC?

See here: https://forum.doom9.org/showthread.php?p=1859759#post1859759

[K4sum1]

See here: https://forum.doom9.org/showthread.php?p=1859759#post1859759

Ok, I found dBpoweramp, and that works fine for my purposes. Bit janky at times but might actually use it instead of LameXP from now on.

I like ALAC because Windows shows the track ID tags on it, unlike FLAC, and I have some older Apple devices that only support ALAC.

Sorry for the late reply, I had forgotten that I made the post.

[TomServo]

We use LameXP on a Windows 10 machine to encode mp3 files in bulk to a normalized mp3 at 96kbps CBR, mono. This is done on external hard drives. We copy the encoded files to a master and a backup. We noticed that the resulting encoded files are severely fragmented, which makes them copy extremely slowly unless we optimize the external HDD after each bulk encoding. Using the Windows HDD Analyze tool after encoding a batch, it always shows fragmentation. Then we optimize the HDD, but the next time we encode a batch the Analyzer shows high fragmentation again. Is there any insight into this? Something we could do differently to help mitigate this? I can provide more information about the LameXP settings and environment if needed. Thank you!

[LoRd_MuldeR]

We use LameXP on a Windows 10 machine to encode mp3 files in bulk to a normalized mp3 at 96kbps CBR, mono. This is done on external hard drives. We copy the encoded files to a master and a backup. We noticed that the resulting encoded files are severely fragmented, which makes them copy extremely slowly unless we optimize the external HDD after each bulk encoding. Using the Windows HDD Analyze tool after encoding a batch, it always shows fragmentation. Then we optimize the HDD, but the next time we encode a batch the Analyzer shows high fragmentation again. Is there any insight into this? Something we could do differently to help mitigate this? I can provide more information about the LameXP settings and environment if needed. Thank you!

Well, the exact way how the operating system (file system) allocates "blocks" for new files on the HDD is not under the control of user-space applications. When a new file is created, or more data is appended to existing file, the file system necessarily needs to find and allocate the required number of "free" blocks on the HDD, so that the data can actually be stored. The file system should prefer to allocate a contiguous range of blocks for each file, but this may not always be possible – in which case "fragmentation" happens. This is especially true when multiple files are written out at the same time: The data of the files that are written out in parallel will have to be "interleaved" in some sort of way.

This means that while running multiple encoder processes in parallel, as LameXP does by default, results in improved usage of modern multi-core CPU and therefore will speed-up the overall process, it also is susceptible to more fragmentation.

Of course, you can simply restrict the number of parallel encoder processes, even to one, in order minimize fragmentation. But this will probably result in a massive slow-down. You can't have your cake and eat it too! :D

(BTW: On modern SSDs fragmentation is a non-issue. So probably the "best" solution would be to encode to an SSD and stop worrying about fragmentation altogether. You still could copy/move the files to a mechanical HDD later on)

[TomServo]

Ok, that makes sense. We used to use a software called "Audiobook Cutter" that merged all the new encoded files in a folder into one file, and then wrote, one by one, new files in ~10 minute segments. We stopped doing that, and that's when this issue was noticed. Now that I know this information, hopefully we can come up with a solution to mitigate it instead of having to purchase 20+ SSDs to replace these.

[bigdog660]

Hi, I've been trying to convert AAC in a MP4 container to MP3. I get the following error:

LameXP v4.19 (Build #2320), compiled on 2021-08-29 at 18:25:44

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

The format of this file is NOT supported:
C:/Users/rgeer/Downloads/test.mp4

Container Format: dash
Audio Format: Type: AAC, Profile: LC, Bitrate: 126 kbps

Media info gives me this:

General
Complete name : C:\Users\rgeer\Downloads\test.mp4
Format : dash
Codec ID : dash (iso6/mp41)
File size : 3.87 MiB
Duration : 4 min 15 s
Overall bit rate : 127 kb/s
Encoded date : UTC 2017-03-21 21:11:13
Tagged date : UTC 2017-03-21 21:11:13

Audio
ID : 1
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 4 min 15 s
Bit rate : 126 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 3.82 MiB (99%)
Encoded date : UTC 2017-03-21 21:11:13
Tagged date : UTC 2017-03-21 21:11:13

Is there any chance this may be fixed or feature added in the future? Thanks!

[manolito]

You can find information and methods to open this DASH format here:
https://filext.com/file-extension/DASH

[LoRd_MuldeR]

Even though your file has a .mp4 file extension, it's not a "regular" MP4 container, but DASH (https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP) format. This format is not currently supported :scared:

I don't know whether FAAD supports this kind of file, but I doubt it. If it does, then support for DASH input could be added to LameXP. You could always try yourself:
faad.exe -o output.wav your_input.mp4

If FAAD cannot handle this kind of file directly, maybe you could use MP4box to demux the AAC stream?

[lvqcl]

IIRC it's possible to remux it from DASH-MP4 to regular MP4 using ffmpeg.

[bigdog660]

Thanks for all the info guys. ffmpeg does the job, but I was liking the LameXP GUI. I finally used my head, and found a ffmpeg GUI that works well enough for DASH to MP3 conversion. For kicks and giggles, I'll give FAAD and MP4box try and report back soon. Been a long time since I've used them independently.

[SeeMoreDigital]

Why not de-mux the elementary AAC audio stream out of the .mp4 container prior to re-encoding to .mp3?

EDIT: That being said... Why bother re-encoding to mp3 when LC-AAC at the same bit-rate is superior?!

[mike20021969]

Hi.

With AAC encoding:
Could you include as an additional option format ADTS (Audio Data Transport Stream) with an .aac file extension?
Thanks.

[LoRd_MuldeR]

It appears that QAAC has an option to output ADTS, but neither FDKAAC nur NeroAAC has such option.

Why would you need ADTS anyway? MP4 is, by far, the most widely used standard container for AAC. Also, you can always demux from the MP4 container, e.g. by using MP4Box.

[LoRd_MuldeR]

LameXP v4.20 Beta-2

Changes between v4.19 and v4.20:
* Updated MediaInfo to v22.03 (2022-03-31), compiled with ICL 2021.2 and MSVC 15.9
* Implemented workaround for DwmEnableBlurBehindWindow() not working on Windows 11

[shades]

Dear LoRd_Mulder!

I hope you are well!
I have a feature request, perhaps you could consider please?

When converting to .wav on the slider it just says, (uncompressed) for obvious reasons.
Could this be changed to (samplerate) and do a up-downsample conversion and maybe a Stereo/Mono selector?

This would make this an extremely useful tool for me. I need to change samplerates and mono conversion all the time working with stems etc.

Thanks for your time working on this great tool.

[WSC4]

Can you correct your uninstaller to remove all files please? I have installed and uninstalled a few times, but files are left over in directories. The main problem is in the registry HKEY_CLASSES_ROOT shell. And this was a bad problem. Thanks.

[LoRd_MuldeR]

Can you correct your uninstaller to remove all files please? I have installed and uninstalled a few times, but files are left over in directories. The main problem is in the registry HKEY_CLASSES_ROOT shell. And this was a bad problem. Thanks.
Which files exactly do you mean that are left over after uninstall?

Also, first you talk about files, then suddenly you are referring to the registry key HKEY_CLASSES_ROOT. Those are two entirely different things. So, is this about files or registry entries? :confused:

[WSC4]

Which files exactly do you mean that are left over after uninstall?

Doing a search for lamexp of the entire drive for system files and folders, hidden files and folders and subfolders came up with lamexp in the file name. I have forgotten how many.

Also, first you talk about files, then suddenly you are referring to the registry

Perhaps I should have written "Also, the main problem is in the registry..." or "Another problem is in the registry...".

In Registry Editor, Edit, Find and entering lamexp found it in the HKEY_CLASSES_ROOT.

I did this because sometime after uninstalling LameXP, I was in Windows Explorer and right clicked to "Open With" a 7-Zip file and LameXP was listed to open the .7z file.

[LoRd_MuldeR]

Doing a search for lamexp of the entire drive for system files and folders, hidden files and folders and subfolders came up with lamexp in the file name. I have forgotten how many.
LameXP installer does not "create" any files, other than those extracted to the selected install directory. The only exception of this probably are the shortcuts created in the start menu and on the desktop.

The uninstaller is supposed to remove the LameXP install directory as well as the shortcuts that were created during install.

If you think this doesn't work as expected, then you need to re-produce the problem and provide more detailed information! Otherwise, it will be next to impossible to have this fixed...

In Registry Editor, Edit, Find and entering lamexp found it in the HKEY_CLASSES_ROOT.
Well, the key HKEY_CLASSES_ROOT is used to store information about file types.

LameXP needs to modify entries in this key in order to add the shell command "Convert this file with LameXP" to all supported file types – provided that you enable the "Shell integration" option in the program. However, this is not so simple, because, in the HKEY_CLASSES_ROOT key, file extensions (e.g. ".mp3") are mapped to file types (e.g "Winamp.File.MP3"). And it is the file types that we need to modify! Consequently, for all supported file extensions, we first have to figure out the corresponding file types. Then, we can add our shell operation to each file type that was found in the previous step. So, to make a long store short, the list of file types that we need to modify is not fixed and is not known in advanced!

Because it cannot be known in advance which keys in HKEY_CLASSES_ROOT we will have to modify on a specific machine, there is no simple way to remove those entries in the uninstaller. You would probably think that we could simply scan the entire HKEY_CLASSES_ROOT key and remove every "ConvertWithLameXP" sub-key. But keep in mind that the (un)installer is created with NSIS, so we are pretty much limited to removing hard-coded registry keys :rolleyes:

I did this because sometime after uninstalling LameXP, I was in Windows Explorer and right clicked to "Open With" a 7-Zip file and LameXP was listed to open the .7z file.
LameXP will never add the "ConvertWithLameXP" operation to the .7z file extension.

If, however, the file extension .7z happens to be associated with the same file type as one of the file extensions supported by LameXP (e.g. .mp3), then we could end up in a situation where the operation "ConvertWithLameXP" appears for .7z files too, even though this was unintended. To make it clear again: LameXP does not create such situation by itself! But, if such situation exists on your system, then there is hardly anything we could do about it...

[danlock]

Thanks for the recent update. I downloaded it today and am very impressed and very pleased.

thanks!

[WSC4]

@danlock

https://www.videohelp.com/software/TAudioConverter

[LoRd_MuldeR]

LameXP v4.21 has been released :)
https://github.com/lordmulder/LameXP/releases/latest

Changes between v4.20 and v4.21 [2023-12-29]:
* Upgraded build environment to Microsoft Visual Studio 2019.11 (MSVC 16.11)
* Updated the Windows SDK version to 10.0.19041.0
* Updated LAME encoder to v3.101 Beta-3 (2023-12-15), compiled with ICL 2023.2 and MSVC 16.11
* Updated Opus encoder/decoder libraries to v1.4+9 (2023-11-03) and Opus-Tools to v0.2+34 (2023-11-12)
* Updated Monkey's Audio binary to v10.38 (2023-12-22), compiled with ICL 2024.0 and MSVC 16.11
* Updated FLAC encoder/decoder to v1.4.3 (2023-06-23), compiled with ICL 2024.0 and MSVC 16.11
* Updated mpg123 decoder to v1.32.3 (2023-10-02), compiled with GCC 13.2.0
* Updated MediaInfo to v23.11 (2023-11-30), compiled with ICL 2023.2 and MSVC 16.11
* Updated cURL to v8.5.0 (2023-12-06), with libcurl v8.5.0 and OpenSSL v1.1.1w
* Updated QAAC add-in (separate download) to QAAC v2.80 (2023-07-05), compiled with ICL 2024.0 and MSVC 16.11
* Updated ALAC decoder to refalac v1.80 (2023-07-05), compiled with ICL 2024.0 and MSVC 16.11
* Added an option to disable the icon in the notification area (now disabled by default)
* Updated language files (big thank-you to all contributors !!!)Download updated version of the QAAC add-in here:
LameXP.qaac-addin.2023-12-18.zip (https://sourceforge.net/projects/lamexp/files/Miscellaneous/Add-ins/qaac/LameXP.qaac-addin.2023-12-18.zip/download)

[SeeMoreDigital]

Super duper... Thank you my Lord :)

[bar72]

Just like to say many thanks for this. Saved me a ton of time with a bunch of DVDs I was transcoding to mkv. Handy it normalises surround files with ease.

[MrVideo]

I'm fairly certain that I've done this before, but now it doesn't want to import FLAC files. Complains that the file format could not be recognized.

The files are created by ExactAudioCopy. Here is the mediainfo output of one of the files:
General
Complete name : F:\CDRips\WT40-2004-04\WT40-2004-04-1\01 - WT40-2004-04-Track01.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 87.8 MiB
Duration : 16 min 27 s
Overall bit rate mode : Variable
Overall bit rate : 746 kb/s
Album : WT40-2004-04-1
Part : 1
Part/Position : 1
Part/Total : 4
Track name : Track01
Track name/Position : 01
Track name/Total : 4
Performer : WT40-2004-04
Encoded by : Exact Audio Copy (Burst mode)
Genre : CHR
Recorded date : 2004
Writing library : FLAC.EXE -8 -V -T "MONOSTEREO=-" -T "ARTIST=WT40-2004-04" -T "TITLE=Track01"
-T "ALBUM=WT40-2004-04-1" -T "DATE=2004" -T "TRACKNUMBER=01" -T "GENRE=CHR" -T "COMMENT="
-T "BAND=" -T "ALBUMARTIST=" -T "COMPOSER=" -T "DISCNUMBER=1" -T "TOTALDISCS=4"
-T "TOTALTRACKS=4" --picture="C:\Users\brown\AppData\Local\Temp\CPI8B1D.tmp" -o
Cover : Yes / Yes
Cover description : CD Front Cover
Cover type : Cover (front) / Cover (front)
Cover MIME : image/ / image/jpeg
MCDI : Yes
MONOSTEREO : -

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 16 min 27 s
Bit rate mode : Variable
Bit rate : 744 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 44.1 kHz
Bit depth : 16 bits
Compression mode : Lossless
Stream size : 87.5 MiB (100%)
Writing library : libFLAC 1.4.3 (UTC 2023-06-23)
Audacity reads in the file without any issues.

The files are written as FLAC, instead of WAV so that the metadata can be added.

Any thoughts? Something I can try?

[SeeMoreDigital]

I'm fairly certain that I've done this before, but now it doesn't want to import FLAC files. Complains that the file format could not be recognized.

The files are created by ExactAudioCopy. Here is the mediainfo output of one of the files: -


General
Complete name : F:\CDRips\WT40-2004-04\WT40-2004-04-1\01 - WT40-2004-04-Track01.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 87.8 MiB
Duration : 16 min 27 s
Overall bit rate mode : Variable
Overall bit rate : 746 kb/s
Album : WT40-2004-04-1
Part : 1
Part/Position : 1
Part/Total : 4
Track name : Track01
Track name/Position : 01
Track name/Total : 4
Performer : WT40-2004-04
Encoded by : Exact Audio Copy (Burst mode)
Genre : CHR
Recorded date : 2004
Writing library : FLAC.EXE -8 -V -T "MONOSTEREO=-" -T "ARTIST=WT40-2004-04" -T "TITLE=Track01"
-T "ALBUM=WT40-2004-04-1" -T "DATE=2004" -T "TRACKNUMBER=01" -T "GENRE=CHR" -T "COMMENT="
-T "BAND=" -T "ALBUMARTIST=" -T "COMPOSER=" -T "DISCNUMBER=1" -T "TOTALDISCS=4"
-T "TOTALTRACKS=4" --picture="C:\Users\brown\AppData\Local\Temp\CPI8B1D.tmp" -o
Cover : Yes / Yes
Cover description : CD Front Cover
Cover type : Cover (front) / Cover (front)
Cover MIME : image/ / image/jpeg
MCDI : Yes
MONOSTEREO : -

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 16 min 27 s
Bit rate mode : Variable
Bit rate : 744 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 44.1 kHz
Bit depth : 16 bits
Compression mode : Lossless
Stream size : 87.5 MiB (100%)
Writing library : libFLAC 1.4.3 (UTC 2023-06-23)


Audacity reads in the file without any issues.

The files are written as FLAC, instead of WAV so that the metadata can be added.

Any thoughts? Something I can try?What settings are you using with MediaInfo to obtain a report like that?

[LoRd_MuldeR]

I'm fairly certain that I've done this before, but now it doesn't want to import FLAC files. Complains that the file format could not be recognized.
Can you please share your log (https://lamexp.sourceforge.net/doc/Manual.html#options-for-debugging) and/or provide a sample file?

[MrVideo]

What settings are you using with MediaInfo to obtain a report like that?
View -> text
File -> Export -> text

[SeeMoreDigital]

View -> text
File -> Export -> text
Hmmmm... I don't understand what this is: -

Writing library : FLAC.EXE -8 -V -T "MONOSTEREO=-" -T "ARTIST=WT40-2004-04" -T "TITLE=Track01"
-T "ALBUM=WT40-2004-04-1" -T "DATE=2004" -T "TRACKNUMBER=01" -T "GENRE=CHR" -T "COMMENT="
-T "BAND=" -T "ALBUMARTIST=" -T "COMPOSER=" -T "DISCNUMBER=1" -T "TOTALDISCS=4"
-T "TOTALTRACKS=4" --picture="C:\Users\brown\AppData\Local\Temp\CPI8B1D.tmp" -o

I haven't seen it before in a MediaInfo file report.

[MrVideo]

Can you please share your log (https://lamexp.sourceforge.net/doc/Manual.html#options-for-debugging) and/or provide a sample file?
http://vidiot.com/Zipfiles/lamexp_sample.zip

While I turned the console on, I can't cut-n-paste the text from the console. The sample file should provide the same error.

For some reason, the image is not liked (skipping unsupported image track).

Audio file format could *not* be recognized.

Then the file was rejected.

[MrVideo]

Hmmmm... I don't understand what this is: -

Writing library : FLAC.EXE -8 -V -T "MONOSTEREO=-" -T "ARTIST=WT40-2004-04" -T "TITLE=Track01"
-T "ALBUM=WT40-2004-04-1" -T "DATE=2004" -T "TRACKNUMBER=01" -T "GENRE=CHR" -T "COMMENT="
-T "BAND=" -T "ALBUMARTIST=" -T "COMPOSER=" -T "DISCNUMBER=1" -T "TOTALDISCS=4"
-T "TOTALTRACKS=4" --picture="C:\Users\brown\AppData\Local\Temp\CPI8B1D.tmp" -o

I haven't seen it before in a MediaInfo file report.
I see that all the time, especially in mkv video files. It displays the command that created the file. In this case, EAC runs the external flac program to convert the ripped wave file to FLAC.

[SeeMoreDigital]

Mine look like this: -

General
Complete name : \\Synology_NAS\My Music\My Albums (2.0) CD's\Beatles, The\[1969] Abbey Road [2019 CD]\Abbey Road.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 279 MiB
Duration : 47 min 30 s
Overall bit rate mode : Variable
Overall bit rate : 822 kb/s
Album : Abbey Road
Performer : The Beatles
Genre : Rock
Recorded date : 1969 [2019]
Cover : Yes
Cover type : Cover (front)
Cover MIME : image/jpeg

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 47 min 30 s
Bit rate mode : Variable
Bit rate : 821 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 44.1 kHz
Bit depth : 16 bits
Compression mode : Lossless
Stream size : 279 MiB (100%)
Writing library : libFLAC 1.4.3 (2023-06-23)
MD5 of the unencoded content : 6338CCADBA82E0BA336659B09AD9E5B9

[LoRd_MuldeR]

http://vidiot.com/Zipfiles/lamexp_sample.zip

The sample file should provide the same error.

For some reason, the image is not liked (skipping unsupported image track).

Audio file format could *not* be recognized.

Then the file was rejected.
I can reproduce your problem. Here is the full MediaInfo outpu in XML format that LameXP will process:
https://pastebin.com/tQb86gSR

This part definitely looks weird (not a valid MIME type string), and it's probably the reason why the image isn't extracted correctly:
<Cover_Mime>image/ / image/jpeg</Cover_Mime>

Could be a bug/quirk in MediaInfo :confused:

Anyways, even if we can't recognize the image (cover art), we still should be able to detect the file type. I suppose more in-depth analysis will be needed :rolleyes:


While I turned the console on, I can't cut-n-paste the text from the console.

With Windows' standard terminal emulator, hold down the left mouse button to select and then a single right click will copy the selection to clipboard.

[MrVideo]

I can reproduce your problem. Here is the full MediaInfo outpu in XML format that LameXP will process:
https://pastebin.com/tQb86gSR
Glad that you can reproduce.

What am I supposed to do with it in regards to LameXP? I noticed that all of the paths in the file pertain to your system.
With Windows' standard terminal emulator, hold down the left mouse button to select and then a single right click will copy the selection to clipboard.
That's just it, holding down the left button doesn't select anything. It is completely ignored in the console terminal. (Win7-64) Even the scroll wheel is ignored.

I await word. It will kinda suck if the image can't be copied over to the MP3 file. But, it will not be the end of the world if it doesn't.

[LoRd_MuldeR]

What am I supposed to do with it in regards to LameXP? I noticed that all of the paths in the file pertain to your system.
You don't. At this point, I will need to do some in-depth debugging, when I have more time (probably at the WE).

[MrVideo]

You don't. At this point, I will need to do some in-depth debugging, when I have more time (probably at the WE).
Sorry, I misunderstood. I read the posting and thought you meant I was supposed to feed it to LameXP on my system. I look forward to your finding(s).

[LoRd_MuldeR]

My analysis shows that, for your specific sample file, MediaInfo's output (XML) is missing the <Format>FLAC</Format> tag in the "general" section. Actually, there's no <Format> tag in the "general" section tag at all :confused:

All my other FLAC files, and actually all my audio files, do have a proper <Format> tag in the "general" section.

Consequently, I have now opened an issue at MediaInfo project, because at the moment I would suspect a problem on their side:
https://github.com/MediaArea/MediaInfo/issues/1088#issue-2991294402

[MrVideo]

My analysis shows that, for your specific sample file, MediaInfo's output (XML) is missing the <Format>FLAC</Format> tag in the "general" section. Actually, there's no <Format> tag in the "general" section tag at all :confused:

All my other FLAC files, and actually all my audio files, do have a proper <Format> tag in the "general" section.

Consequently, I have now opened an issue at MediaInfo project, because at the moment I would suspect a problem on their side:
https://github.com/MediaArea/MediaInfo/issues/1088#issue-2991294402
I must be missing how things work. So, why doesn't LameXP like the FLAC files? What does MediaInfo have to do with this? Yes, I am really confused.

In other words, what is different in my FLAC file that is different your FLAC file that trips up the error? I'm guessing that the flac program that EAC uses is a little different than the flac program that you use?

[SeeMoreDigital]

Did/can you provide a sample?

[lvqcl]

http://vidiot.com/Zipfiles/lamexp_sample.zip


Mp3tag shows that this file has FLAC tags, but also it has ID3v1 and ID3v2 tags.

[LoRd_MuldeR]

I must be missing how things work. So, why doesn't LameXP like the FLAC files? What does MediaInfo have to do with this? Yes, I am really confused.
LameXP is a GUI front-end. It uses various CLI tools "under the hood". For example, MediaInfo is used for detecting the file types of the given input files as well as for extracting the meta tags (including artwork).

Therefore, if MediaInfo doesn't recognize your file, or if MediaInfo produces inconclusive results for your file, as is the case here, then we have a problem ;)

In other words, what is different in my FLAC file that is different your FLAC file that trips up the error? I'm guessing that the flac program that EAC uses is a little different than the flac program that you use?

I'm not sure. I haven't seen this problem with any of my files. Might be related to the ID3 tags. Anyway, since the problem has been confirmed by the MediaInfo developer, we can hope for a fix...

[SeeMoreDigital]

Mp3tag shows that this file has FLAC tags, but also it has ID3v1 and ID3v2 tags.
Ah... So that's the stuff I didn't understand...

[MrVideo]

I'm not sure. I haven't seen this problem with any of my files. Might be related to the ID3 tags. Anyway, since the problem has been confirmed by the MediaInfo developer, we can hope for a fix...
Here is what is really weird. I can rip music CDs and LameXP has no issue importing those flac files (I just checked). I just looked again at the track and the <Format>FLAC</Format> line is there in the "General" section.

I wonder if the issue is the image type, since none of the music CDs that I rip contain any images, i.e., I never insert a cover image (too lazy to scan the cover and add it to the rip). For the WT40 rips, I use the same image for all of them.

Hopefully there is a new version soon.

[MrVideo]

Anyway, since the problem has been confirmed by the MediaInfo developer, we can hope for a fix...
Ya, hopefully soon. No update in the bug database entry you pointed to.

[SeeMoreDigital]

Do you need the 'flac tags'. What happens if you remove them, does everything work correctly?

[lvqcl]

I wonder if the issue is the image type

The real issue is the presence of ID3 tags in your FLAC file. Their presence make it invalid.

Uncheck "Add ID3 tag" option in EAC settings.

[LoRd_MuldeR]

Hopefully there is a new version soon.
Patience is a virtue. I built the new version of MediaInfo tonight, and it indeed seems to fix the problem with your file. New build of LameXP with updated MediaInfo is up now :)
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2025-04-16/

[MrVideo]

Patience is a virtue. I built the new version of MediaInfo tonight, and it indeed seems to fix the problem with your file. New build of LameXP with updated MediaInfo is up now :)
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2025-04-16/
Thanks. Downloaded and installed. And yep, the files are now indeed read in.

So, what was MediaInfo's issue? The previous version did work if the ID3 tag wasn't there.

Thanks for your help in getting this figured out.

[MrVideo]

I am correct in assuming that LameXP will not traverse directories looking for audio files?

[MrVideo]

Cannot assign process to job: Process is not running anymore!
Failed to assign process to job object!
The job has 339 files to convert to MP3. At about 160 done it started doing the errors. Now, at about 248 left, the error is occurring at pretty much every conversion. As indicated, the error is not fatal, as the conversion takes place.

I figured that I should report it anyway.

[LoRd_MuldeR]

So, what was MediaInfo's issue? The previous version did work if the ID3 tag wasn't there.
I'm not exactly sure. The commit that fixed it can be seen here (https://github.com/MediaArea/MediaInfoLib/commit/170b40db6684916115958da06ad748f7ca3b4399). Seems to be related to the order in which certain things are done.

I am correct in assuming that LameXP will not traverse directories looking for audio files?
Depends on whether you select "Open Folder" or "Open Folder Recursively" from the "File" menu, I suppose.

The job has 339 files to convert to MP3. At about 160 done it started doing the errors. Now, at about 248 left, the error is occurring at pretty much every conversion. As indicated, the error is not fatal, as the conversion takes place.

We use a job object (https://learn.microsoft.com/en-us/windows/win32/procthread/job-objects) to manage the sub-processes started by LameXP. This is mainly done in order to ensure that no "orphaned" sub-processes will be left behind, when the main (GUI) process is terminated for whatever reason. Sometimes it can happen, though, that the new sub-process has already terminated before we even had a chance to assign it to the job object. This is the warning you are seeing. In other words, it is harmless and can be ignored :)

[MrVideo]

Depends on whether you select "Open Folder" or "Open Folder Recursively" from the "File" menu, I suppose.
Never use the pulldown menu. I drag-n-drop. I'll have to remember that for next time.

[libing114]

How to stop LameXP v4.21 from showing the "Check for updates" window every time it is launched? "Disable update reminder" has already been chosen.

[LoRd_MuldeR]

How to stop LameXP v4.21 from showing the "Check for updates" window every time it is launched? "Disable update reminder" has already been chosen.
Please see here:
https://github.com/lordmulder/LameXP/issues/126

[manolito]

@ libing114

Hi,

I used to become a little mad by this intrusive behavior of LameXP, I hardly use it any more, and upgrading is not really an option.

My solution was to use one of those "Clicker Applications" which can automatically click away intrusive messages (I still use the ancient ClickOff app). There is still a small delay before the software starts, but it is quite short and not really annoying...


Cheers
manolito

[shiro]

~removed double post~

(duplicate of https://github.com/lordmulder/LameXP/issues/126#issuecomment-3218243384)

[LoRd_MuldeR]

There is no need to double-post! I have already replied to your comment on GitHub:
https://github.com/lordmulder/LameXP/issues/126#issuecomment-3218295391

[MrVideo]

Is there a new beta available? Currently running 4.22 Beta 1 build 2389. The update check fails as it can't connect to the server.

[LoRd_MuldeR]

LameXP v4.22 Beta-2
https://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2026-01-17/

Changes between v4.21 and v4.22:
* Updated MediaInfo to v25.03 (2025-03-21), compiled with ICL 2024.2 and MSVC 16.11
* Updated cURL to v8.18.0 (2026-01-07), with libcurl v8.18.0 and OpenSSL v3.5.4

[MrVideo]

Thanks.