LameXP v4.21 Final · Build #2382 (2023-12-29) [Archive] - Page 21

jpsdr

12th May 2014, 15:46

... 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

12th May 2014, 15:54

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

12th May 2014, 16:20

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

13th May 2014, 10:01

Ok, thanks for your answers.

LoRd_MuldeR

19th May 2014, 19:12

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

25th May 2014, 14:29

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

25th May 2014, 16:06

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

25th May 2014, 17:58

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

25th May 2014, 18:27

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

25th May 2014, 22:51

: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

25th May 2014, 23:23

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

27th May 2014, 17:38

LoRd_MuldeR

27th May 2014, 21:08

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

27th May 2014, 21:43

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

28th May 2014, 01:25

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

28th May 2014, 05:57

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

28th May 2014, 12:09

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

29th May 2014, 06:08

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

29th May 2014, 12:24

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

29th May 2014, 13:00

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

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

LoRd_MuldeR

29th May 2014, 13:10

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

29th May 2014, 13:17

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

29th May 2014, 13:35

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

29th May 2014, 15:21

LoRd_MuldeR

29th May 2014, 15:52

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

29th May 2014, 16:35

...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

29th May 2014, 21:31

It sort of works now, see the messages.

LoRd_MuldeR

30th May 2014, 18:22

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

31st May 2014, 06:39

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

31st May 2014, 14:01

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

31st May 2014, 14:38

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

31st May 2014, 14:59

LoRd_MuldeR

9th June 2014, 13:12

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

10th June 2014, 03:53

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

23rd June 2014, 22:54

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

24th June 2014, 06:03

Thank you! :)

LoRd_MuldeR

27th June 2014, 16:39

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

4th July 2014, 02:20

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

4th July 2014, 02:36

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

4th July 2014, 08:00

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

4th July 2014, 10:13

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

5th July 2014, 07:14

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

5th July 2014, 07:40

"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

5th July 2014, 17:48

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

7th July 2014, 07:14

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.