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

LoRd_MuldeR

1st November 2010, 22:45

LameXP - Audio Encoder Front-End

LameXP is a graphical user-interface (front-end) for various of audio encoders: It allows you convert your
audio files from one audio format to another one in the most simple way. Despite its name, LameXP is NOT only
a front-end for the LAME encoder, but supports a wide range of output formats, including MP3, Ogg Vorbis,
AAC/MP4, FLAC, AC-3 and Wave Audio. The number of supported input formats is even bigger! Furthermore LameXP
does NOT only run on Windows XP, but also on Windows Vista, Windows 7 and many other operating systems.

As all the encoders and decoders used by LameXP are already "built-in" (with one exception), you do NOT need
to install any additional software, such as "Codecs", "Filters" or "Plug-ins", on your computer. Everything
works "out of the box"! You can even use LameXP as a "portable" application, e.g. run it from your USB stick.
Moreover LameXP was designed for batch processing. This means that you can convert a huge number of audio
files, e.g. a complete album or even your entire music collection, in a single step. And, as LameXP is able
to process several audio files in parallel, it takes full advantage of modern multi-core processors! However
LameXP is NOT only optimized for speed, it also provides excellent sound quality by using the most
sophisticated encoders available and by giving the user unrestricted control over all encoding parameters.

In addition to that, LameXP provides full support for metadata, including cover art. So when converting your
audio files, LameXP will retain existing meta tags. But there also is an easy-to-use editor for adding or
modifying metadata. LameXP supports Unicode for both, meta tags and filenames, so there won't be any problems
with "foreign" characters. And, thanks to our translators, the user-interface of LameXP is available in
multiple languages. Last but not least, LameXP supports a number of post-processing filters, including sample
rate conversion, normalization (gain), tone adjustment and downmixing of multi-channel sources.

Click here to view a live (animated) demo! (http://lamexp.sourceforge.net/demo.html)

http://lamexp.sourceforge.net/img/tour_lamexp_1.png (http://lamexp.sourceforge.net/demo.html)
http://lamexp.sourceforge.net/img/tour_lamexp_2.png (http://lamexp.sourceforge.net/demo.html)
http://lamexp.sourceforge.net/img/tour_lamexp_3.png (http://lamexp.sourceforge.net/demo.html)

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 !!!)

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 !!!)

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

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 !!!)

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 !!!)

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 !!!)

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 !!!)

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 !!!)

Download latest LameXP version (binary and sources) here:
https://github.com/lordmulder/LameXP/releases/latest
http://sourceforge.net/projects/lamexp/files/
https://osdn.net/projects/lamexp/releases/
https://bitbucket.org/muldersoft/lamexp/downloads
https://www.assembla.com/spaces/lamexp/documents
https://www.mediafire.com/folder/nbkdinut804o2/LameXP
http://www.free-codecs.com/lamexp_download.htm
http://www.videohelp.com/tools/LameXP

Call for translators:
We will need new translations for LameXP v4.xx, so translators are more than welcome!
A guide for LameXP v4.xx translators is available from this (http://lamexp.sourceforge.net/doc/Translate.html) location now.

Reviews of LameXP can be found here:
http://www.softpedia.com/reviews/windows/LameXP-Review-214285.shtml
http://www.betanews.com/article/LameXP-A-great-audio-encoder-by-any-other-name/1308263706

Before reporting problems or asking for help, please see the User's Manual (http://lamexp.sourceforge.net/doc/Manual.html) !!!Occasionally your anti-virus program may mistakenly(!) detect malware ("virus", "trojan horse", "worm", etc.)
in LameXP. This is called a "false positive" and the file is actually innocent/clean. It's an error in your
specific anti-virus software. So in case you encounter such problems, please use http://www.virustotal.com/,
http://www.virscan.org/ or a similar online-service to check the file in question with multiple(!) anti-virus
engines. Especially take care with heuristic scan results like "suspicious", "generic" or "packed". Such
results are NOT confirmed malware detections - they are speculative and almost always can be ignored safely! (http://lamexp.sourceforge.net/doc/FAQ.html#96205e91)

SeeMoreDigital

1st November 2010, 23:07

Cool....

parsifal

2nd November 2010, 11:13

Excellent news, LoRd_MuldeR!

I know that it doesn't say much, coming after the fact, but in the past I thought about suggesting to you a Qt transition...

boyumeow

2nd November 2010, 14:58

No wonder long time never saw any update from your LameXP, and U have put your Delphi IDE to the shelf, and indeed it have help U with your coding well. I shall test your LameXP v4 since I faced what U have describe about unicode support. Thanks for your great new and improve LameXP, and enjoy your everyday happily.

Dark Eiri

2nd November 2010, 16:30

Wow, it looks pretty! Great news!

LoRd_MuldeR

2nd November 2010, 21:13

Excellent news, LoRd_MuldeR!

I know that it doesn't say much, coming after the fact, but in the past I thought about suggesting to you a Qt transition...

Well, after having spent about one week trying to figure out how to do the most simple things with MFC, I gave up on MFC and decided to spend one day with Qt. And although I never had used Qt before, I got my first Qt application running after less than an hour. IMO the framework is really well-designed and straightforward! So I decided to do more projects with it ;)

boyumeow

3rd November 2010, 04:10

Just thought to post what it look likes in my pc and whether to what your have plan, design and coding. Thanks.

http://img708.imageshack.us/img708/2553/lamexpv4a.th.png (http://img708.imageshack.us/i/lamexpv4a.png/)

LoRd_MuldeR

6th November 2010, 03:43

New build up. Reading meta information via MediaInfo should work now, including Unicode support.

(Double-click file in the list to show detailed information)

mariush

6th November 2010, 05:04

Had to disable AVG to make it run, its heuristics detects Qtcore4.dll as virus. Stupid AVG.

It's nice.. though there's lots of nitpicks I found about it but those are relatively normal for a tech preview.

Among I could mention, the output directory tree and a stupid behavior of accessing each subfolder when going in a subfolder, for example here's what happens when I clicked on the + icons in the tree going in a folder:

http://savedonthe.net/thumbnail/726.jpg (http://savedonthe.net/view/726/badqt.png)

See? It queries the whole tree each time you click on a folder going deeper, which is kinda bad if you'd access a network drive for example if for some reason the OS doesn't cache it..

In addition, the output directory tree, when clicking on + to expand a drive, it automatically gets info from each file - it should only seek using FOLDERS OR LINK, not any kind of file. Maybe it's my antivirus though - I'm not sure.

Start File Monitor from SysInternals, set the filter to include only *lamexp* and you'll see what it happens.

There's also not detecting if a folder has subfolders or not, that blue rectangle popping up when the input folder tree gets focus.. you can select any kind of file (extension i mean but maybe it's because it's tech preview), not being able to select different output folders for each track (though this maybe is by design or not yet implemented).. there's usage of / instead of \ in the path above the output tree which may confuse people... some typo "loacated" ... i hope the program won't take that much time to load everytime it starts because of that extracting process ... and last the about sound is really childish and the least you could have made it play asynchronously so I don't get the feeling program is frozen while sound plays. :)

later edit: wonder why that tree thing only happens on drive C: and not drive T: or K: for example...

LoRd_MuldeR

6th November 2010, 12:18

The behavior of the directory is kind of strange. I only noticed it is a bit slower than it should be.

Problem is that there's not much I can do here, because I use a QTreeView widget with a QFileSystemModel object as the model and that is it ;)

I could try to implement my own model, but that's not a priority currently. And actually I'd prefer to use theirs.

BTW: The use of "/" instead of "\" is because Qt is cross-platform and always uses "/" instead of the "native" separator for Strings that contain a path.

I could use QDir::toNativeSeparators() every single time I output a path string to the GUI though, if people prefer to see a "\" character...

mariush

6th November 2010, 16:33

Just curious... have you considered doing LameXP with Lazarus (free pascal for windows)? It's cross compiling and supports 32bit and 64bit Windows, with native unicode support and just tried it.. seems to work just fine.

LoRd_MuldeR

6th November 2010, 17:03

LoRd_MuldeR

6th November 2010, 22:50

The "Meta Information" dialog should be complete now, including edit capability:

http://img837.imageshack.us/img837/1907/metainformationbuckethe.png

MatLz

7th November 2010, 22:30

Well done !
But...
A mirror plz ? :D

LoRd_MuldeR

7th November 2010, 23:28

Well done !
But...
A mirror plz ? :D

Can't access the MediaFire server? Anyway, I have uploaded to an additional mirror this time.

MatLz

7th November 2010, 23:45

:thanks: for the mirror.

(Don't forget) I'm on a phone.
Mediafire did never work for me.

O.K. I will test this new version.
:thanks: for it

mariush

8th November 2010, 00:08

Mulder, what's wrong with placing the files directly on the space I'm giving you for free :)? I really don't mind, but it's your call, maybe you have other reasons not to use it.

In other news...AVG's heuristics still sucks:

http://savedonthe.net/image/729/badavg.png

LoRd_MuldeR

8th November 2010, 00:32

Don't worry, I will make the "release" versions available through my usual download system, which includes your server. Just not the early preview builds.

About the AVG issue: It appears that A/V developers still are a bit too paranoid about EXE packers. They really should tell people that when a file has been "detected" by a heuristic then that file with high probability is NOT malicious at all. Instead they show the potential threat in a similar way to a "true" approved virus signature match. It's not a big surprise that the average user doesn't know what "generic" or "heuristic" means in this context, so they will think it's indeed a virus and thus send hate mail to the software author instead of bug report to the A/V developer team :rolleyes:

[EDIT]

Here is a VirusTotal analysis. Only 3 A/V programs out of 42 trigger a false alert:
http://www.virustotal.com/file-scan/report.html?id=4411eb50ccaf0b2871a644087fb88c82fcd4f5e5cfaa49436c797dcfb428d0db-1289178340

boyumeow

8th November 2010, 06:34

mariush

8th November 2010, 09:03

Mulder, that's OK, I know they're not viruses, it's just annoying. AVG 8.5 Small Business I have now is stupid but that's what worked on Windows 2003.

It will have to do until I install Windows 7 I bought almost a year ago and NOD32 I bought half a year ago - both still sealed in their boxes. I'm just too lazy and don't feel like reinstalling SVN servers, visual studio and all the other programming crap... it's a pain.

LoRd_MuldeR

8th November 2010, 14:09

Hi LM, the drop down menu has shown three arrows (2 up and 1 down), would it be better with 2 only (1 up and 1 down), just my little suggestion.
http://img248.imageshack.us/img248/9233/lamexpv45.png (http://img248.imageshack.us/i/lamexpv45.png/)

Please ignore me if I have hinder your progress. Thanks.

That's simply how the "Plastique" Qt style looks :p

I have no control over how the standard controls look in particular. And I'm certainly not planning to write my own Qt style ;)

If you don't like how the "Plastique" style looks, you can switch to "Cleanlooks" or native "Windows" style :)

boyumeow

10th November 2010, 06:12

Haha, it look nice for me too, just abit uneasy with 3arrows ;p. I thought the styles was your control, not mine. Anyway, this kind of look like "Cleanlooks" to me (not fussy, simple, easy, straight forward, clean look, etc...). Thanks.

LoRd_MuldeR

11th November 2010, 01:08

Today I managed to create a "static" build. So now have a single "stand-alone" EXE file, just like in the old v3.xx series. Also the "Meta Data" tab has been implemented.

ckmox

12th November 2010, 18:30

wow it looks fancy too bad im bad at C++ or C in general as it has pointers that i dont understand

but anyway is their a way to hide the console or command prompt while running it?

LoRd_MuldeR

12th November 2010, 18:35

but anyway is their a way to hide the console or command prompt while running it?

Not yet. But the final version won't have a console (by default), of course ;)

ckmox

12th November 2010, 18:39

Not yet. But the final version won't have a console (by default), of course ;)

ah kk thanks ill watch this thread for the final release

LoRd_MuldeR

15th November 2010, 22:53

Getting LAME to handle Unicode filenames and tags was harder than I though :o

Apparently the current LAME v3.98 release version doesn't support Unicode at all (at least on Windows), so I had to compile a LAME v3.99 Alpha build from the sources.

As a result MP3 encoding should work now. But currently only WAV and MP3 files will work as source, as the decoders aren't "activated" yet...

SeeMoreDigital

15th November 2010, 23:45

Errrrm....

Any chance you could add AC3 encoding? Best mate!

LoRd_MuldeR

16th November 2010, 00:04

Errrrm....

Any chance you could add AC3 encoding? Best mate!

Should be possible to integrate Aften. But there are many other things I need to finish first, before integrating new features...

boyumeow

18th November 2010, 11:20

LoRd_MuldeR

18th November 2010, 21:02

http://img171.imageshack.us/img171/3838/lamexpv41.png
Is this correct at the moment for Nero AAC encoder, console show found but process failed. I have the required files in the folder.

Nope, it's not correct. That works for me (tested on WinXP and Win7). I will try to add more detailed error output...

(I have to ask: You are 100% sure your "NeroAacEnc.exe" works?)

http://img171.imageshack.us/img171/660/lamexpv42.png
And what is this :sly:.
:D, thanks and enjoy yourself.

That's the upcoming "encoding" dialog. In the current build it doesn't do much yet. It's merely a mockup at the moment ;)

SeeMoreDigital

19th November 2010, 11:27

Nope, it's not correct. That works for me (tested on WinXP and Win7). I will try to add more detailed error output...

(I have to ask: You are 100% sure your "NeroAacEnc.exe" works?)

This happens for me also. On both my Windows7 PC's.

I copied all three Nero ".exe" files from my LameXP v3.18 Hotfix-2 Build 88 folder...

LameXP - Audio Encoder Front-End
Version 4.00 TechPreview, Build 40 [2010-11-18], MSVC compiler v15.00
Copyright (C) 2004-2010 LoRd_MuldeR <MuldeR2@GMX.de>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License <http://www.gnu.org/>.
This program comes with ABSOLUTELY NO WARRANTY.

CPU brand string: Intel(R) Atom(TM) CPU 230 @ 1.60GHz
CPU signature: Family: 6, Model: 28, Stepping: 2
CPU capabilities: MMX: 1, SSE: 1, SSE2: 1, SSE3: 1, SSSE3: 1, x64: 0
CPU no. of cores: 2

Using Qt Framework v4.7.1, compiled with Qt v4.7.1
Running on Windows 7 or Windows Server 2008 R2.

Library Path:
C:/Program Files/LameXP v4.00 TechPreview [Build #40]

Note: This demo (pre-release) version of LameXP will expire at 2010-12-02.

Thread is doing something important... Done

Extracting file: alac.exe
Extracting file: faad.exe
Extracting file: flac.exe
Extracting file: gpgv.exe
Extracting file: lame.exe
Extracting file: MAC.exe
Extracting file: mediainfo_icl11.exe
Extracting file: mpcdec.exe
Extracting file: mpg123.exe
Extracting file: oggdec.exe
Extracting file: oggenc2_gen.exe
Extracting file: oggenc2_p4.exe
Extracting file: selfdelete.exe
Extracting file: shorten.exe
Extracting file: speexdec.exe
Extracting file: takc.exe
Extracting file: ttaenc.exe
Extracting file: valdec.exe
Extracting file: volumax.exe
Extracting file: wget.exe
Extracting file: wupdate.exe
Extracting file: wvunpack.exe
All extracted.

Found Nero AAC encoder binary:
C:/Program Files/LameXP v4.00 TechPreview [Build #40]/neroAacEnc.exe

Nero process failed to create!
Error message: "Process failed to start: No such file or directory"

Thread is doing something important... Done

LoRd_MuldeR

19th November 2010, 13:23

Hmmmm, this hardly makes any sense:

Found Nero AAC encoder binary:
C:/Program Files/LameXP v4.00 TechPreview [Build #40]/neroAacEnc.exe

Nero process failed to create!
Error message: "Process failed to start: No such file or directory"

We check first for the existence of the 'neroAacEnc.exe' and only if it does exist we try to execute it :confused:

So the only way for this to happen is that the 'neroAacEnc.exe' disappeared during the three nanoseconds between the file.exists() and the process.start().

This of course is EXTREMELY unlikely. So are you sure that you aren't fooled by a buggy A/V software?

(Anyway, I added yet another check that will check for the existence of the file once again after the process failed to create. Just to be sure...)

By the way: Do other features that involve creating a process work for you? What about MediaInfo and LAME?

For example: Can you open files on the "Source Files" tab and get the correct meta info? Can you encode files to the MP3 format by clicking "Encode Now!" button?

By the way 2.0: My main development machine is running Windows 7 too, so this can't be a portability issue either.

LoRd_MuldeR

20th November 2010, 03:35

Okay, moving towards a first alpha release:

MP3 encoding should work alright now - in the progress window and with multiple instances running in parallel.

Still only Wave and MP3 files will be handled as input. Getting some decoders to work is the next step...

Taurus

20th November 2010, 14:24

Originally Posted by SeeMoreDigital

Found Nero AAC encoder binary:
C:/Program Files/LameXP v4.00 TechPreview [Build #40]/neroAacEnc.exe

Nero process failed to create!
Error message: "Process failed to start: No such file or directory"

Same here.
LameXP v4.00 TechPreview [Build #50]
WinXP Pro 32bit
And yes, verified the Nero files are in the root folder of Lame XP...
The same files are working with your v3.18 Hotfix-2, Build 88

LoRd_MuldeR

20th November 2010, 14:38

What is the message after "Error message: "Process failed to start: No such file or directory"?

Also, do you use any A/V software that might mess with the program? And do MediaInfo and LAME fail too or only NeroAAC ???

If this is not caused by third-party software (e.g. buggy A/V software), it can only be cause by a bug in either Qt or the Windows operating system.

However the problem doesn't show up on any of my test systems, strangely enough...

--[EDIT]--

Wait! If you rename the install folder to "C:\LameXP" or something else that does NOT contain any white-spaces, is the problem resolved ???

LoRd_MuldeR

20th November 2010, 16:09

Darn! I think the mystery is resolved:

There actually are two versions of the QProcess.start() function: One which takes only a single string (complete command-line) and one which takes a string (path to EXE) plus a string-list (command-line arguments). In all places I always used the second one, except for the Nero version check, where I implicitly used the first one, as there were no arguments to pass. Unfortunately it turns out that while the second version correctly wraps all arguments which contain white-spaces into quotes (including the path to the EXE file!), the first version does NOT do so. For this reason Windows couldn't find the Nero executable, if (and only if) the install path contains any white-spaces. I will now enforce the use of the second version also for the Nero executable and the problem should be gone once and for all...

(BTW: Of course on my test system I always put the executables into "C:\Test" and thus the problem never showed up. That's life.)

Taurus

20th November 2010, 16:20

LameXP - Audio Encoder Front-End
Version 4.00 TechPreview, Build 50 [2010-11-20], MSVC compiler v15.00
Copyright (C) 2004-2010 LoRd_MuldeR <MuldeR2@GMX.de>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License <http://www.gnu.org/>.
This program comes with ABSOLUTELY NO WARRANTY.

CPU brand string: AMD Athlon(tm) processor
CPU signature: Family: 6, Model: 10, Stepping: 0
CPU capabilities: MMX: 1, SSE: 1, SSE2: 0, SSE3: 0, SSSE3: 0, x64: 0
CPU no. of cores: 1

Using Qt Framework v4.7.1, compiled with Qt v4.7.1
Running on Windows XP.

Library Path:
C:/Audio/Lame XP

Note: This demo (pre-release) version of LameXP will expire at 2010-12-04.

Thread is doing something important... Done

Extracting file: alac.exe
Extracting file: faad.exe
Extracting file: flac.exe
Extracting file: gpgv.exe
Extracting file: lame.exe
Extracting file: MAC.exe
Extracting file: mediainfo_icl11.exe
Extracting file: mpcdec.exe
Extracting file: mpg123.exe
Extracting file: oggdec.exe
Extracting file: oggenc2_gen.exe
Extracting file: oggenc2_p4.exe
Extracting file: selfdelete.exe
Extracting file: shorten.exe
Extracting file: speexdec.exe
Extracting file: takc.exe
Extracting file: ttaenc.exe
Extracting file: valdec.exe
Extracting file: volumax.exe
Extracting file: wget.exe
Extracting file: wupdate.exe
Extracting file: wvunpack.exe
All extracted.

Found Nero AAC encoder binary:
C:/Audio/Lame XP/neroAacEnc.exe

Nero process failed to create!
Error message: "Process failed to start: No such file or directory"

File 'C:/Audio/Lame XP/neroAacEnc.exe' does exist?
Yes, it still exists
!
Thread is doing something important... Done

This is on an old Athlon Pc mostly used for audio encoding...
Will try on a double and quad core intel later on.
Anti virus = off :D

Edit: You are faster.. I've read your comment above.
If you want me to test a new alpha, go ahead.

And yes, Lame encoding is doin fine.
Dont know about Mediainfo because it is icl11. I highly doubt it is working on an old Athlon.
How to verify?

SeeMoreDigital

20th November 2010, 16:21

(BTW: Of course on my test system I always put the executables into "C:\Test" and thus the problem never showed up. That's life.)That's sussed it :D

Placing the LameXP folder in the "C:\root" area instead of within the "Program Files" folder solves the Nero exe issue...

LameXP - Audio Encoder Front-End
Version 4.00 TechPreview, Build 50 [2010-11-20], MSVC compiler v15.00
Copyright (C) 2004-2010 LoRd_MuldeR <MuldeR2@GMX.de>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License <http://www.gnu.org/>.
This program comes with ABSOLUTELY NO WARRANTY.

CPU brand string: Intel(R) Core(TM)2 Duo CPU T5800 @ 2.00GHz
CPU signature: Family: 6, Model: 15, Stepping: 13
CPU capabilities: MMX: 1, SSE: 1, SSE2: 1, SSE3: 1, SSSE3: 1, x64: 0
CPU no. of cores: 2

Using Qt Framework v4.7.1, compiled with Qt v4.7.1
Running on Windows 7 or Windows Server 2008 R2.

Library Path:
C:/LameXP

Note: This demo (pre-release) version of LameXP will expire at 2010-12-04.

Thread is doing something important... Done

Extracting file: alac.exe
Extracting file: faad.exe
Extracting file: flac.exe
Extracting file: gpgv.exe
Extracting file: lame.exe
Extracting file: MAC.exe
Extracting file: mediainfo_icl11.exe
Extracting file: mpcdec.exe
Extracting file: mpg123.exe
Extracting file: oggdec.exe
Extracting file: oggenc2_gen.exe
Extracting file: oggenc2_p4.exe
Extracting file: selfdelete.exe
Extracting file: shorten.exe
Extracting file: speexdec.exe
Extracting file: takc.exe
Extracting file: ttaenc.exe
Extracting file: valdec.exe
Extracting file: volumax.exe
Extracting file: wget.exe
Extracting file: wupdate.exe
Extracting file: wvunpack.exe
All extracted.

Found Nero AAC encoder binary:
C:/LameXP/neroAacEnc.exe

Thread is doing something important... Done

Cheers

LoRd_MuldeR

20th November 2010, 16:28

Taurus

20th November 2010, 16:45

You got it!
Nero fixed.

boyumeow

21st November 2010, 15:16

Hi LM, just read your pm and yes it was solved as reported by others too. Thanks for your attention and patient with it. Just need to confirm from you, should we (or could we) report any bugs now to you, as I think your might want to configure properly your LameXP v4 first before handling bugs (I need to make sure that I dun hinder your work). Anyway, I've already bother you with 1, so here is another 1.
http://img20.imageshack.us/img20/447/lamexpv43v.png
As you can see the "Save output files to the same location where the input file is located" is not working as I have come across, not sure whether you have already configure it (as I was typing now, just found out the last word 'loacated' was believed to spell wrongly too:p).
Sorry to point out your mistake (I feel as if I'm picking your fault, sorry about it). Thanks and enjoy your coding:).

edit: I keep reporting about bugs, I should be telling you I have success in re-encoding my mp3s with my Chinese title in English environment Windows Vista. Thanks again.

LoRd_MuldeR

21st November 2010, 16:16

The "Save output files to the same location where the input file is located" checkbox does not do anything at the moment.

And you see those "????" in the console, because the console doesn't handle Unicode well. But internally LameXP does handle Unicode, so don't worry ;)

LoRd_MuldeR

21st November 2010, 23:30

The "Save output files to the same location where the input file is located" checkbox does not do anything at the moment.

Now it does :)

boyumeow

22nd November 2010, 08:56

And you see those "????" in the console, because the console doesn't handle Unicode well. But internally LameXP does handle Unicode, so don't worry ;)

Hehe, I do understand those "????" in the console, I was trying to point out "save output ..." not working (i.e music/folder/???.mp3 to music/???.mp3). Guess there is too many question marks and you have miss the back-slash :p.

Mis-spell : http://img716.imageshack.us/img716/6717/lamexpv43.png :p

Is "Meta Data" suppose to be working yet? Cause the following picture is what I get from 'with and without option enabled'.

http://img716.imageshack.us/img716/9109/lamexpv44.png

All is not hurry, take your time and do enjoy your time (does it sound I'm hurrying you :devil:).

Thanks again and Take Care cause I need your apps :p.

LoRd_MuldeR

22nd November 2010, 14:23

Yes, writing the meta data is supposed to work and it does work for me.

http://img534.imageshack.us/img534/410/clipboard25.th.png (http://img534.imageshack.us/img534/410/clipboard25.png)

Please make sure that the meta data was detected correctly by MediaInfo (check "Show Details" on the "Source Files" tab) and also make sure you use a proper tool to check the encoded file.

I wouldn't trust Windows Explorer on this! I usually use MediaInfo, Winamp and VLC Player for this purpose...

(BTW: Creating a playlist is only grayed out when "Save output files to the same location where the input file is located" is checked. Where should the playlist file go in that case? ^^)

LoRd_MuldeR

23rd November 2010, 00:08

Now a log for each job will be created. You can double-click an item in the progress window in order to make the log show up.

boyumeow

24th November 2010, 06:03

(BTW: Creating a playlist is only grayed out when "Save output files to the same location where the input file is located" is checked. Where should the playlist file go in that case? ^^)

Go to "Save output files to the same location where the input file is located" :p, not sure it make sense to U or not, or it could just be "Music" folder (Not the option that I usually will use, cause sometime I just play all my songs :p).

U are right about using mediainfo than Windows Explorer, but I had to point out that your previous LameXP could write the Meta Data and shown by Windows Explorer. I had to specify clearly that I just want the knowledge of the possibility, and not asking U to change your apps to make Windows Explorer to recognize the Meta Data. In my words, sometime I do feel Windows Explorer is just using too many resources rather than just show me what I have written. Anyway, I still feel my Win Vista is not functioning as expected. Please do ignore this question if I'm rude and ask too much (Will delete this question if it is inappropriate).

Thanks again :).

LoRd_MuldeR

24th November 2010, 08:11

Actually we can only speculate why Explorer fails to read out the meta info.

The one difference between the "old" version and the "new" version is that now Unicode tags are handled properly, i.e. they are written with the proper UTF-8 encoding, instead of local 8-Bit.

If the Windows Explorer (or whatever Shell Extension is responsible for reading the meta info) doesn't handle such tags, there's nothing I could do.

With MediaInfo and Winamp you can prove that the tags are there. I certainly won't revert to the old unsafe/unreliable method, just because Explorer is stupid once again.

(About putting the playlist file into the "My Music" folder: I think this would be kind of arbitrary. Also we'd have to use absolute paths in the playlist file then, which is "suboptimal" at least!)

LoRd_MuldeR

26th November 2010, 00:51

Now with 100% more Ogg Vorbis support ;)

Taurus

26th November 2010, 10:55

Now with 100% more Ogg Vorbis support ;)
Not working here..
LameXP - Audio Encoder Front-End
Version 4.00 TechPreview, Build 85 [2010-11-26], compiled with MSVC 9.0
Copyright (C) 2004-2010 LoRd_MuldeR <MuldeR2@GMX.de>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License <http://www.gnu.org/>.
This program comes with ABSOLUTELY NO WARRANTY.

CPU vendor id : AuthenticAMD (Intel: 0)
CPU brand string : AMD Athlon(tm) processor
CPU signature : Family: 6, Model: 10, Stepping: 0
CPU capabilities : MMX: 1, SSE: 1, SSE2: 0, SSE3: 0, SSSE3: 0, x64: 0
Number of CPU's : 1

Using Qt Framework v4.7.1, compiled with Qt v4.7.1
Running on Windows XP.

Library Path:
C:/Audio/Lame XP Test Versions

Note: This demo (pre-release) version of LameXP will expire at 2010-12-10.

Thread is doing something important... Done

Extracting file: alac.exe
Extracting file: faad.exe
Extracting file: flac.exe
Extracting file: gpgv.exe
Extracting file: lame.exe
Extracting file: MAC.exe
Extracting file: mediainfo_icl11.exe
Extracting file: mpcdec.exe
Extracting file: mpg123.exe
Extracting file: oggdec.exe
Extracting file: oggenc2_i386.exe
Extracting file: oggenc2_sse2.exe
Extracting file: oggenc2_x64.exe
Extracting file: selfdelete.exe
Extracting file: shorten.exe
Extracting file: speexdec.exe
Extracting file: takc.exe
Extracting file: ttaenc.exe
Extracting file: valdec.exe
Extracting file: volumax.exe
Extracting file: wget.exe
Extracting file: wupdate.exe
Extracting file: wvunpack.exe
All extracted.

Found Nero AAC encoder binary:
C:/Audio/Lame XP Test Versions/neroAacEnc.exe

Thread is doing something important... Done

Analyzing: C:/Dokumente und Einstellungen/FrozenOne/Eigene Dateien/My Dropbox/Vo
rschläge/John Mayer - Gravity.mp3
All files added.

Process thread {a2cffe1f-fff3-4d88-8df5-afef5311e954} has started.
Running jobs: 0

Mediainfo(Tags) doing allright.

LoRd_MuldeR

26th November 2010, 10:59

Did you look at the log? (I mean the job's log in the processing dialog, not the console)

Anyway, it seems like you are trying to feed the Ogg Vorbis encoder with an MP3 source, which won't work until I have implemented encoder-independent decoders.

As I cannot do everything at once, MP3 encoding works only with Wave/MP3/MP2 sources and Vorbis encoding works only with Wave sources currently...

Taurus

26th November 2010, 11:15

Ok, you got it. Wav -> ogg is nice.
Sorry to publish false alarms.
Didn't see the log window. It was overlayed by the console in the foreground. My fault.

LoRd_MuldeR

26th November 2010, 11:25

Didn't see the log window. It was overlayed by the console in the foreground. My fault.

Huh?

The log window doesn't even exist unless you double-click the failed item in the processing window - after all jobs are completed.

But once activated, the log window should be modal (i.e. stay on top of the other window).

(BTW: Actually it turns out that OggEnc2 does handle FLAC input just fine, so I'll allow FLAC sources for Vorbis encoding)

Taurus

26th November 2010, 12:11

Got it :p

LoRd_MuldeR

28th November 2010, 22:58

New build up: The auto-update system should work now :)

(Note: Currently the auto updater will only launch the installer with UAC disabled. That's on Vista/Win7 only, XP should be okay. I will implement a fix tomorrow)

LoRd_MuldeR

29th November 2010, 10:22

Note: Currently the auto updater will only launch the installer with UAC disabled. That's on Vista/Win7 only, XP should be okay. I will implement a fix tomorrow

Issue resolved, hopefully.

Please note that Vista/Win7 users might need to update to Build #97 manually, before the Auto-Update to Build #98 will work as expected.

(BTW: Build #97 and Build #98 are identical, except for the build number. That's just for testing the auto-update system!)

LoRd_MuldeR

2nd December 2010, 00:24

Today I have implemented decoder support. Currently MP3 and Vorbis decoding are supported.

This means that we should now be able to "cross encode" from MP3 to Vorbis or from Vorbis to MP3. More decoders will be integrated soon.

(Note: Due to a limitation of OggDec.exe, decoding of Vorbis files with Unicode characters in the name may fail!)

LoRd_MuldeR

3rd December 2010, 01:29

(Note: Due to a limitation of OggDec.exe, decoding of Vorbis files with Unicode characters in the name may fail!)

Should be fixed now.

Also AAC sources should be handled now, from both, ADTS and MP4 containers. AAC encoding support not added yet, but soon.

(Had to hack Unicode support into FAAD myself too. It's a pity that all those CLI tools don't support Unicode file names out-of-the-box :rolleyes:)

LoRd_MuldeR

4th December 2010, 00:04

AAC encoding should be working now. Just remember to drop Nero AAC Encoder into the same folder as LameXP.

(If you wonder why the progress doesn't update smoothly when encoding to AAC: That's because Nero AAC doesn't flush its STDOUT after writing out status updates. I cannot do anything about that)

LoRd_MuldeR

6th December 2010, 01:05

The Windows 7 Taskbar features should be back now :)

(This also means that you'll need the Platform SDK v7.1 to compile LameXP now, at least if you want the Taskbar features to work)

LoRd_MuldeR

8th December 2010, 23:00

Due to a stupid mistake of mine, in the Build #132 encoding didn't work at all. Unfortunately even the auto-update will fail with the "problematic" build :o

So in case you get an NSIS install error during update, which complains that the access to the TEMP folder was denied, then you will have to download/install the new build manually this time.

The problem should be fixed in Build #136, at least I hope so. Moreover another installer issue, which caused the installer to launch in background, has been resolved.

SeeMoreDigital

8th December 2010, 23:16

Cheers :)

Motenai Yoda

11th December 2010, 03:01

bug report, why when I edit some meta data options and re-run the changes have not been saved?
also i should can help for the Italienisch:p

LoRd_MuldeR

11th December 2010, 03:07

bug report, why when I edit some meta data options and re-run the changes have not been saved?

So you mean you edit the meta data of some file on your list, close the edit dialog and when you re-open the edit dialog the changes have been lost? :confused:

If so, what if you don't re-open the edit dialog and just proceed to the encode? Will the encoded files contain the meta info you entered?

[EDIT]

If you mean that you completely exit LameXP after editing the meta data but before starting the encoding process, then your changes will be lost for sure.

That's because LameXP won't save your edits when you terminate the program. The meta data will be "saved" by embedding it into the encodes files ^^

also i should can help for the Italienisch

It's to early to start translating at this time, because a lot of things are still unfinished and bigger changes might happen.

But I'll yet you know when I'm ready to accept translations...

Motenai Yoda

11th December 2010, 21:16

LoRd_MuldeR

11th December 2010, 21:28

no I'm meaning that i edit some things like comment and position to "not specified" but on exiting from lamexp those changes were lost, while the un-check on playlist and metadata seems to be stored...

As explained above, if you edit the meta data that has been read from your source files but then exit LameXP without actually running the encode, your edits are "lost".

The one and only method to "save" you edits is starting the encode, because then the edited meta data will be written to the encoded files...

also I would suggest a rename pattern field, to generate the namefile by metadata.

That makes a lot of sense. And it's on my TODO list :)

LoRd_MuldeR

12th December 2010, 23:06

WMA decoding should work now. Unfortunately "wmawav.exe" neither handles Unicode filenames nor does it report progress information.

(If anybody knows a better command-line tool to decode WMA files to Wave, please tell me!)

Inventive Software

13th December 2010, 20:25

Hey Mulder.

Love the program, used it for a couple of years now as it's great at simple conversion.

I now have a need to convert about 1700 songs from FLAC to MP3, which your program does great. These are in separate album folders. Last time I attempted this was with version 3.18 H2, and it didn't keep the directory structure when writing the MP3 files, so all the files ended up in one directory. Correctly named, but a nightmare organising the files.

Does version 4 have this or not? :)

LoRd_MuldeR

13th December 2010, 21:13

Does version 4 have this or not? :)

It doesn't. At least not yet. However this doesn't mean it can't be added, but I don't have a good idea how to do it at the moment :)

Assuming we have the full paths of various source files as well as the full path of the destination folder, how to figure out which segment of the source path to append to the output path?

Always appending the full source file path (except for the drive letter, of course) to the output path might not be the best idea.

If the paths of all source files have a common prefix, it might make sense to ignore that prefix and only keep the part of the paths that differs. But that isn't that trivial to implement ;)

(At least the "keep it simple and stupid" solution, always append the full path, would be straight forward to implement. But an exam will prevent me form coding the next 2 days)

boyumeow

15th December 2010, 11:19

My gosh... U r having a exam before X'mas, should I say it is good to have it before the holidays ;P. Take Care and Enjoy your holidays season.

LoRd_MuldeR

16th December 2010, 00:54

My gosh... U r having a exam before X'mas, should I say it is good to have it before the holidays ;P. Take Care and Enjoy your holidays season.

Holidays? Isn't that the time where you finally get a chance to do all the pending work that has aggregated? :p

@topic: FLAC support has been added.

boyumeow

16th December 2010, 05:27

LoRd_MuldeR

16th December 2010, 22:19

@Request: Would it be difficult or impossible to add "midi to wav", as I've some midi files to convert to mp3. I had to apologize that I do not know whether there is such 'convert midi to wav' apps. Anyway, I use some recording function from a apps and save it in wave format, then use your app to encode into MP3 format. Thought I could save my time if Your apps could do such wonders :sly:.

MIDI files don't store audio signals. They store "notes". More specifically MIDI files store control instructions for instruments, like keyboards or synthesizers or drum-computers.

Consequently you cannot "convert" MIDI files to Wave. What you can do is using your sound-card as synthesizers and feed the MIDI instructions to it in order to "execute" the MIDI file.

That's what actually happens when you "play" the MIDI file in a media player. And of course the synthesizer's (sound card's) output could be "captured" to a Wave file.

However I'm not aware of a suitable CLI tool to integrate into LameXP that does both, use your sound card to "play" the MIDI file and "capture" the output as PCM data to a Wave file.

If you could point me to such a tool, I could integrate it into LameXP. Still the result would vary between different systems, as different systems use different sound cards...

(BTW: If you wonder why the web-site is down, it's because the web-hoster claimed the site caused too much load, although only 14 of 100 GB traffic have been used this month)

johnsonlam

18th December 2010, 18:55

Time to unveil the secret:
* Full Unicode support, which means that all problems with "Codepages" and "strange characters" will finally be gone!
* Support for multiple platforms (Windows, Linux, MacOS X) will be possible.

1) Unicode problem gone
2) Portable

Excellent job!

LoRd_MuldeR

19th December 2010, 02:18

1) Unicode problem gone
2) Portable

Excellent job!

LameXP has always been "portable" in the way that the EXE file works "out-of-the-box" with no "installation" necessary.

The LameXP installer essentially is an SFX archive. The only exception (at the moment) is the optional WMA Decoder, which needs to be installed locally.

By the way: With the latest build encoding from Multichannel sources to MP3 should work now (thanks to SoX).

LoRd_MuldeR

20th December 2010, 00:30

Today I implemented support for AC-3 and DTS sources :)

Also a stupid mistake, which caused LameXP to complain if less than 222 GB of free diskspace are available, has been fixed. Of course this should be 2 GB ;)

boyumeow

20th December 2010, 04:38

222GB... I have partition my hdd to lesser amount, no harm with that complain, just annoying :sly:. Guess U have study too much, need a good new pair of spectacle or magnifying glass, just like me :p.

Just for your info, about the detail info from the windows explorer view I complain, it is working as it is in Win7. Guess my Vista have limitation or some bugs. So sorry for my previous post about it.

Thanks and have a great day rest, especially U might be preparing for next coming exams :D.

LoRd_MuldeR

20th December 2010, 15:02

222GB... I have partition my hdd to lesser amount, no harm with that complain, just annoying :sly:. Guess U have study too much, need a good new pair of spectacle or magnifying glass, just like me :p.

Of course 222 GB was used for testing only, so I could trigger the warning dialog without actually having to lower my diskspace to 2 GB ;)

This should have never gone into a "public" build, but I just forgot to change the threshold value back to 2 GB before I released the "problematic" build.

It has been fixed in the latest build, so never mind!

LoRd_MuldeR

22nd December 2010, 02:18

The "Drop Box" widget has been implemented.

LoRd_MuldeR

23rd December 2010, 00:55

The installer should work on Windows 2000 again. It seems the NSIS "LockedList" Plug-in is broken on Windows 2000 :rolleyes:

LoRd_MuldeR

2nd January 2011, 04:04

I finally implemented the translation system. Currently only English and German translations are available.

This also means that translators can have their fun now :)

If you are interested in translating LameXP, you should make yourself familiar with the Qt Linguist (http://doc.qt.nokia.com/latest/linguist-translators.html) tool first. Then you can start translating from the (latest!) "Blank.ts" file, which you can find here (https://github.com/lordmulder/LameXP/tree/master/etc/Translation).

When Linguist asks for Settings the first time you open the TS file, you should keep "Source language" at "English/Any Country" and change "Target language" to whatever you are going to translate to.

BTW: I also updated MediaInfo to the latest SVN version, which should fix MediaInfo crashes with certain MP3 files (details (http://forum.doom9.org/showthread.php?p=1467016#post1467016)).

boyumeow

2nd January 2011, 07:00

LoRd_MuldeR

2nd January 2011, 16:41

Hi LM, hope U have enjoy your holidays well :p.

Not sure r U joking with us, but I'm getting this with build 210 in Vista32

http://img827.imageshack.us/img827/8385/lamexpv47.png

Hope it really a joke, please advise. Thanks.

Nope, it's NOT a joke, of course!

You shouldn't launch LameXP with elevated rights (admin), as it was designed to operate with "normal" rights (user). If you launch LameXP with elevated rights, then all the tools launched by LameXP (like MediaInfo, LAME, OggEnc, and so on) will run with elevated rights too! That's because you can only elevate a process, but once the process has been elevated, it cannot de-elevate itself or create non-elevated child processes (at least I'm not aware of a method). And running the audio tools with elevated rights certainly is NOT a good idea, when processing a lot files that might originate from an "unknown" source...

(If however you get this warning although your are certainly NOT launching LameXP with elevated rights, e.g. "Run as administrator", please let me know. I don't have a Vista machine to test)

[EDIT]

Boyumeow, could you please run the attached tool on your system, once with "Run as administartor" and once without ???

cegy

3rd January 2011, 01:14

Nope, it's NOT a joke, of course!

You shouldn't launch LameXP with elevated rights (admin), as it was designed to operate with "normal" rights (user). If you launch LameXP with elevated rights, then all the tools launched by LameXP (like MediaInfo, LAME, OggEnc, and so on) will run with elevated rights too! That's because you can only elevate a process, but once the process has been elevated, it cannot de-elevate itself or create non-elevated child processes (at least I'm not aware of a method). And running the audio tools with elevated rights certainly is NOT a good idea, when processing a lot files that might originate from an "unknown" source...

(If however you get this warning although your are certainly NOT launching LameXP with elevated rights, e.g. "Run as administrator", please let me know. I don't have a Vista machine to test)

would it be possible to make lamexp run without getting a msg about the elevated rights, maybe a option to turn it off as i DO trust what programs i run as i know where the files are from :rolleyes:

Running on Windows NT 6.1 (win 7)

TokenIsElevated: YES
TokenElevationType: TokenElevationTypeDefault

LoRd_MuldeR

3rd January 2011, 01:36

would it be possible to make lamexp run without getting a msg about the elevated rights, maybe a option to turn it off

Possible, yes. But the whole point is that you shouldn't be running LameXP with elevated rights. What is the point of doing so ???

Simply don't run LameXP with elevated rights and you won't (or at least shouldn't) see the warning :)

as i DO trust what programs i run as i know where the files are from :rolleyes:

That's not the point. The point is that the 100% perfect software doesn't exist in the real world. Even if the software isn't malicious and seems trustworthy, it still may (and most likely does) contain some kind of "vulnerabilities", like potential buffer overflows. New vulnerabilities are revealed almost every day. This applies to commercial software as well as to OpenSource software. An attacker might exploit such vulnerabilities to insert executable code into the program, for example with something as "harmless" as a manipulated MP3 file. In that case the attacker could obtain unlimited access to your system, if the program is running with admin rights. If the program is running with limited access rights, the attacker still might be able to exploit the vulnerability, but he cannot do much harm...

Running on Windows NT 6.1 (win 7)

TokenIsElevated: YES
TokenElevationType: TokenElevationTypeDefault

That's a combination I haven't reproduced locally. I assume this was when you launched the application without "Run as administrator" ???

If so, what UAC level do you have configured in control panel?

(You can find the UAC options under "Start" -> "Control Panel" -> "User Accounts" -> "Change User Account Control settings")

LoRd_MuldeR

5th January 2011, 00:26

Here is an update on the "process elevation" issue:

It seems that on systems with UAC disabled (i.e. lowest UAC level in Windows 7) the "TokenIsElevated" property will always return TRUE, even when the process was not elevated explicitly. Therefore it seems better to check the "TokenElevationType" property instead, which AFAIU will return TokenElevationTypeDefault in that particular case. With UAC enabled it will return either TokenElevationTypeLimited (not elevated) or TokenElevationTypeFull (explicitly elevated). So from now on I will simply look at the "TokenElevationType" and raise the warning only in the case of TokenElevationTypeFull.

http://www.mediafire.com/file/5bneyplcqg2np5s/LameXP.2011-01-04.Release-Static.Build-217.exe

boyumeow

5th January 2011, 06:25

Hi LM, sorry to reply U so late. Guess U have found out about process elevation type, which I was intending to report U with pictures

i.e. "TokenElevationTypeFull"
http://img87.imageshack.us/img87/6870/lamexpv410.png

and "TokenElevationTypeLimited"
http://img600.imageshack.us/img600/2738/lamexpv49.png

with "UAC" turn on,

"TokenElevationTypeDefault"
http://img510.imageshack.us/img510/8334/lamexpv48.png

with "UAC" turn off. In my case, I do have my "UAC" turn off in my Vista32. Got to test the "UAC" before I report it to U.

Phew, guess I can keep my Vista32 for some more time as I was going to ditch it sooner :p. I was planning to compile your LameXP on my own, just to suit my case. Since U have resolved it, guess I can keep my hands off it for the time being :p. Btw, I do not know about programming :o.

Thanks For Your resolution. :thanks:

LoRd_MuldeR

5th January 2011, 16:45

with "UAC" turn off. In my case, I do have my "UAC" turn off in my Vista32. Got to test the "UAC" before I report it to U.

Phew, guess I can keep my Vista32 for some more time as I was going to ditch it sooner :p.

If you already made the move from WinXP to Vista, I can't think of a reason not to update to Win7 as soon as possible, except for the fact that you have to pay for the "update" again (in case you don't have MSDN-AA access). Actually you can think of Vista as a Beta version and of Win7 as the final product. I would also recommend to keep UAC enabled all the time. On Win7 it is much less annoying...

LoRd_MuldeR

8th January 2011, 16:26

Now with 100% more French and Italian, thanks to "Dodich Informatique" and "Roberto" ;)

LoRd_MuldeR

22nd January 2011, 01:56

Beta-1 is out :)

This version features more translations (thanks to all translators!), support for more input formats and finally there are some "advanced options" available.

(Note: My goal is to go for a "Final" release and replace v3.xx soon. So if you find any showstopper bugs, please report immediately!)

boyumeow

22nd January 2011, 03:25

Good news to hear about "advanced options", I'm already impatiently waiting for it :p.

GO GO GO, LM :).

jfcarbel

23rd January 2011, 10:43

Wow, long time LameXP user and glad to see a new version is being worked on. Seems the focus is on Unicode and moving away from Delphi. Is there anything else planned?

I ask because I just recently began looking at fre:ac (http://www.freac.org/) (former known as BonkEnc) and Xrecode (http://xrecode.com/)

As I had a need for an audio conversion tool that also had built in:
- CD conversion on the fly to mp3 with integration to CDDB/freedb for auto tagging
- Normalize via ReplayGain
- metadata cover art support as well

As an added bonus it can take audio from video files including FLV, MP4, VOB. Not sure how often I would use that though.

LoRd_MuldeR

23rd January 2011, 13:34

Seems the focus is on Unicode and moving away from Delphi.

Yes, not being able to handle Unicode file names and meta tags was an annoying limitation. And it is the main reason for the re-write. Delphi 7.0 can handle Unicode (UTF-16) strings too, but it's a real pain, as all the basic string manipulation functions and all the "native" GUI controls are ANSI. This means you'll have to re-write a whole lot of "standard" functions and/or use third-party components all the way. AFAIK newer Delphi versions provide better Unicode support (the basic "String" type is "WideString" now), but the update would be too costly for me and probably break a lot of my code anyway. So I decided to make a clean re-write with C++ and the Qt Framework, which provides full Unicode support as well as a sophisticated "internationalization and localization" tools. And, thanks to Qt, even cross-platform support is within the realms of possibility. However my focus is on Win32 and MSVC for the moment. Next step would be making the application compile with GCC/MinGW too. Then, maybe, make the move to Linux and/or MacOS...

Is there anything else planned?

First of all the goal is to get everything working that had been working under the 3.xx series. This includes encoders (output formats), decoders (input formats), filters and so on. Something that turned out to be a HUGE problem is that most of the command-line tools that I use do not support Unicode file names out-of-the-box! If the GUI front-end handles Unicodes file names just fine all the way, but then the CLI encoder/decoder mangles the commad-line parameters (by converting them them to ANSI and replacing each "foreign" character with a "?" character) you end up with the same Unicode problems as before. Consequently this time I have to make my own custom builds of most CLI tools (rather than using the pre-compiled binaries) and hack Unicode support into their code...

(I still wonder why nobody seems to care about Unicode support in their CLI tools. It's not that hard to do, really! I'm not familiar with their code at all, but I usually can do it within 1-2 hours. A person who is familiar with the code and already has the required build environment set up on his/her machine should be able to do it even faster and much cleaner)

As I had a need for an audio conversion tool that also had built in:
- CD conversion on the fly to mp3 with integration to CDDB/freedb for auto tagging

That's not really in the scope of an audio encoder front-end. There are various CD rippers available, so I don't want to re-invent the wheel. Maybe I will look into "embedding" one of the existing CD rippers, once I run out of ideas for other improvements. Currently there are enough TODO's on my list...

Normalize via ReplayGain

Normalization will be supported, like in the 3.xx version. However I will use Volumax (or SoX) for that purpose.

AFAIK the ReplayGain tool is mainly interesting if you want to "normalize" MP3 and/or AAC files without having to re-encode them (it modifies the MP3/AAC bitstream directly or adds a special tag).

As this is an audio encoder front-end, which you use for the task of re-encoding, we can apply a "hard" normalization just as well...

metadata cover art support as well

This would be possible if: The encoders that are used (LAME, OggEnc2, NeroAAC) support adding "cover art" via command-line and there is a convenient way to extract the cover from existing files. Currently I use MediaInfo to extract all the meta information from the input files. But I don't think it can "extract" the "cover art" too...

After all I really can't understand why people want to have a cover embedded in each audio file. Why not put a plain JPEG file into the "album" folder once, and avoid the redundancy?

(Is that yet another "Apple/iPod" crankiness, like forcing the user to use an incorrect (http://en.wikipedia.org/wiki/MPEG-4_Part_14#.MP4_versus_.M4A_filename_extensions) .m4a extension for MP4 files ???)

As an added bonus it can take audio from video files including FLV, MP4, VOB. Not sure how often I would use that though.

MP4 should work, at least if the audio track is AAC. That's because AAC audio files are usually stored in a MP4 container, regardless of whether they have video or not.

For FLV and VOB, I will have to look into a suitable demuxer. There is "FLV Extract" and it even has a CLI version, but it's written in C# and thus needs the .NET Framework :rolleyes:

(And I want to avoid dependency on the .NET Framework or the Java Runtime Environment by all means. I'm a big fan of "self-contained" and "portable" software ^^)

mariush

23rd January 2011, 14:18

Well, you've lost dependency to .Net and Java but you gained dependency to Qt... ideally, a Windows application wouldn't depending on anything and would follow all the Windows Interface Guidlines so that beginners can get an easy start...

http://www.ics.uci.edu/~kobsa/courses/ICS104/course-notes/Microsoft_WindowsGuidelines.pdf - a bit old and I agree not even Microsoft follows everything in here anymore but it's still a good read

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/welcome.asp
http://msdn.microsoft.com/windowsvista/uxguide
http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterInterfaces.aspx
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e49820cb-954d-45ae-9cb3-1b9e8ea7fe8c

Well anyway, I remember we've talked about it and I understand your decision, but I still felt like saying this for others to read... You can do beautiful apps using just native code - Virtualdub comes to mind for example - but I agree Qt makes it easier. Just not user friendly.

LoRd_MuldeR

23rd January 2011, 15:13

Well, you've lost dependency to .Net and Java but you gained dependency to Qt...

Well, with "dependencies" is was referring to runtime dependencies. More specifically I meant software that the user would have to download and install separately, before he can run/use my software. Of course my software compiled with MSVC and based on the Qt Framework will unavoidably "depend" on the MSVC Runtime libraries, some of the Qt libraries (QtCore and QtGui in this case) as well as various Windows system DLL's. But all these "dependencies" can either be linked in as static libraries (the MSVCRT and the Qt libraries), which completely eliminates the runtime dependency, or they are guaranteed to be available on any Windows system out-of-the-box (the Windows system DLL's). After all, my software is deployed as a single self-contained EXE file that does not depend on any additional software. It runs "out-of-the-box" (i.e. without "installation") on any Windows system from Win2k up to Win7 as well as under Wine. And I think that's what generally is referred to as "portable" software.

(The only exception is the Nero AAC encoder, which cannot be re-distributed along with the application. But that's for legal reasons, not for technical reasons)

ideally, a Windows application wouldn't depending on anything

I have to disagree here. IMO creating a non-trivial GUI application directly on top of the "raw" Win32 API is nothing but pain. It would result in HUGE code that is hard to understand and hard to maintain. In order to deal with this, one would probably start to create his own "wrapper" classes around the "native" Win32 API. You'd end up writing your own GUI Toolkit/Framework. However instead of re-inventing the wheel, you could as well pick one of the existing Frameworks. Even Microsoft has their own GUI Framework for C++ applications on top of the "native" Win32 API, namely MFC (Microsoft Foundation Classes). But IMHO the MFC are a huge mess, compared to Qt or WxWidgets. Also the Qt Framework provides a whole lot of extremely useful non-GUI "helper" classes, which otherwise you would have to either implement yourself or take from other libraries. And, last but not least, the biggest advantage of using a cross-platform Framework instead of the platform-specific Win32 API is that your application will run "natively" on other platforms too...

(EDIT: Of course I agree that avoiding runtime dependencies is preferable. But I don't see a problem with compile-time dependencies, as long as they subserve the project)

and would follow all the Windows Interface Guidlines so that beginners can get an easy start...

My "Interface Guidline" is and always has been: Create software that you would like to use yourself. That plus: Change aspects of the software, if enough people complain ;)

(BTW: When looking at user interfaces as annoying as Windows Media Player 12 or the "Ribbon" interface of Office 2007, I wonder if they still apply any guidelines ^^)

but I agree Qt makes it easier. Just not user friendly.

How is Qt not user friendly? Some of the most intuitive and "user friendly" applications that come to my mind (e.g. SMPlayer) are based on Qt.

And, if desired, Qt can emulate the "look and feel" of Windows ("Classic" and "Luna" as well as "Aero") exactly - I think they even use "native" controls for that purpose.

IMO if an application's user-interface isn't "user friendly", then that's mainly a problem of the design, not so much of the underlying framework...

You can do beautiful apps using just native code - Virtualdub comes to mind for example

Sure, it can be done. But it certainly needs more code (as you have to care about a whole lot of "low level" things) and it's a one-way street.

That's the reason why we won't see a Linux or MacOS port of VirtualDub.

(Also I persoanlly wouldn't call the graphical interface VirtualDub "beautiful", but "no-frills". But that's not necessarily a negative thing)

mariush

23rd January 2011, 16:45

When I say user friendly, I'm talking about something to the terms...Put your grandma in front of the computer and tech her how to use the computer, then tell her to use your software"

You're going to teach her about the Start menu, about the menu and the fact that there will always be File, Edit, View, Help in this order (you have File, View, Tools, ? when you could have Edit to cut or delete files in the queue), so if she wants to save a document she must go to a menu that works with files titled (obviously) "File" and so on, that the Next button should always be on the right of the Previous button, that dialogues should have OK and Cancel and not Cancel and OK on them, that the interface should be easy to use by color blind or people that have to use screen readers because they're legally blind (think for a minute what would a screen reader do when your app will extract all those files in the background for a minute and will keep repeating "extracting lame dot exe dot dot dot new line extracting file : wget dot exe dot dot dot new line...)

Then you have the about window that I already told you about that pops with a scary grawl and is filled with a text that doesn't mean anything aka no legal value (because it's not the full GPL license, a simple scroll bar would fix the problem), the X button in the top corner doesn't work, the Accept button (aka Positive action from the user ) is in the middle while on the main form the positive action is on the left corner (Encode now) and the About button (the most useless because it's also in the ? menu) is in the middle, the center of the action) and so on...

And by the way... if i decline the license once, I can't use the application ever? Maybe I change my mind. Now I can't run it the second time. And it shouldn't close just because I decline the license - the harm was already done, I've already launched the application even though I haven't actually "used" it. I have to edit C:\Documents and Settings\Administrator\Local Settings\Application Data\LoRd_MuldeR\LameXP - Audio Encoder Front-End\config.ini manually to remove that and make it working again (and you're using "Mulder" in registry and Lord_Mulder in app data)

Maybe the better word would be "intuitive"...

http://savedonthe.net/image/838/aac.png

Why the DOS path style?

Why popup with OK saying i don't have WMA, and then a second popup asking if I want to download and install... couldn't it be done in one step... The initial auto update was something like "Search for update" and "Postpone", this one is "Download & install " and "Cancel" ... why not "Postpone" to mantain consistency? Cancel would make me think the application would terminate.

"Goto" Home folder ... goto is not a word.... "Save output ... " is too long to read and complicated... in Meta Data Edit, the positive action, should be on the left of Reset which is sort of a Cancel or undo... checkboxes with [x] don't exist on Windows and confuse user who will think when checked it means "don't do it"...

Compression page shows quality/bitrate min and max, but going toward min increased the quality level which doesn't make sense to a user that doesn't know technology behind - the advanced option gets it right keeping it to Low quality, average, high quality, best etc

http://savedonthe.net/image/839/paths.png

\ and / inconsistency ... and Output dir tab shows path with \ but the source files shows files with / in the panel (I know Windows treats / and \ the same but a Windows user may be puzzled by this /)...

Then all the frills of the QT like blue bars around text boxes, making a dotted rectangle around the buttons that are default (the OK for example if it's the only button on dialogue)... it all makes the interface "bad" for regular users...

LoRd_MuldeR

23rd January 2011, 17:31

Quite a number of suggestions :)

When I say user friendly, I'm talking about something to the terms...Put your grandma in front of the computer and tech her how to use the computer, then tell her to use your software"

You're going to teach her about the Start menu, about the menu and the fact that there will always be File, Edit, View, Help in this order (you have File, View, Tools, ? when you could have Edit to cut or delete files in the queue), so if she wants to save a document she must go to a menu that works with files titled (obviously) "File" and so on, that the Next button should always be on the right of the Previous button, that dialogues should have OK and Cancel and not Cancel and OK on them, that the interface should be easy to use by color blind or people that have to use screen readers because they're legally blind (think for a minute what would a screen reader do when your app will extract all those files in the background for a minute and will keep repeating "extracting lame dot exe dot dot dot new line extracting file : wget dot exe dot dot dot new line...)

If extracting the files takes long on your system, it's probably because of slow A/V software slowing down the process.

On my system it takes ~10 seconds with MSE activated. With MSE de-activated, the extraction process takes like ~1 second (the SSD might be helpful here).

Then you have the about window that I already told you about that pops with a scary grawl and is filled with a text that doesn't mean anything aka no legal value (because it's not the full GPL license, a simple scroll bar would fix the problem), the X button in the top corner doesn't work, the Accept button (aka Positive action from the user ) is in the middle while on the main form the positive action is on the left corner (Encode now) and the About button (the most useless because it's also in the ? menu) is in the middle, the center of the action) and so on...

I'm not a legal expert, but I display exactly the text that the official GPL document says that I'm supposed to attach to my application. Also many applications, that required the user to accept their license terms, do not display the complete license text during install, but only provide a link to the license text instead. As these are programs developed/distributed by big companies, which have a legal department for such questions, I assume it should be okay the way it is (in a legal sense). Most people won't read the whole license text anyway, so providing the link for those who actually are interested seems advisable to me.

And by the way... if i decline the license once, I can't use the application ever? Maybe I change my mind. Now I can't run it the second time. And it shouldn't close just because I decline the license - the harm was already done, I've already launched the application even though I haven't actually "used" it. I have to edit C:\Documents and Settings\Administrator\Local Settings\Application Data\LoRd_MuldeR\LameXP - Audio Encoder Front-End\config.ini manually to remove that and make it working again (and you're using "Mulder" in registry and Lord_Mulder in app data)

Actually the application will call the uninstaller, when you decline the license. You can re-install at a later time, if you changed your mind. That of course can't work when you use the ZIP package, for obvious reasons, so the application will simply quit. Moreover there is no way to ask the user to agree to the license before he launches the application for the first time. So there's not much alternative to asking on the first startup. And that's how it is implemented in many other applications too (here Microsoft's ProcessExplorer and ProcessMonitor tools come to my mind, fore example).

http://savedonthe.net/image/838/aac.png

Why the DOS path style?

If you ask why the path on your screenshot uses "short" (8+3) names, then that's because that is the path from which you launched LameXP on your system. LameXP simply displays the path (command-line argument) that it was launched with. I assume you double-clicked LameXP.exe in WinRAR, so WinRAR did extract the LameXP.exe to the %TEMP% folder and launched it from that location. Of course I have no control over how %TEMP% is defined on your local system. But it seems for reasons of backward compatibility, the %TEMP% environment variable is defined with "short" names on Windows systems by default. However usually you would not run LameXP from your %TEMP% folder, but from something like "C:\Program Files (x86)\LameXP". And in that case you would see the corresponding (long) path...

Why popup with OK saying i don't have WMA, and then a second popup asking if I want to download and install... couldn't it be done in one step... The initial auto update was something like "Search for update" and "Postpone", this one is "Download & install " and "Cancel" ... why not "Postpone" to mantain consistency? Cancel would make me think the application would terminate.

Indeed, it could be done in one step.

"Goto" Home folder ... goto is not a word.... "Save output ... " is too long to read and complicated... in Meta Data Edit, the positive action, should be on the left of Reset which is sort of a Cancel or undo... checkboxes with [x] don't exist on Windows and confuse user who will think when checked it means "don't do it"...

Well, if you have suggestions for better translations, I'm always happy. About the style of the checkboxes: These are Theme-specific.

Compression page shows quality/bitrate min and max, but going toward min increased the quality level which doesn't make sense to a user that doesn't know technology behind - the advanced option gets it right keeping it to Low quality, average, high quality, best etc

That wasn't my idea ;)

It's defined by LAME that "0" means best quality and "9" means worst quality. If I reverse this, it might be more intuitive for newbies, but it wouldn't be consistent with LAME's CLI/manpage anymore and thus confuse the "power" users. So I think it's less confusing to keep it consistent with LAME's docs. And from the labels it should be clear which direction means "better" and which direction means "worse" quality.

http://savedonthe.net/image/839/paths.png

\ and / inconsistency ... and Output dir tab shows path with \ but the source files shows files with / in the panel (I know Windows treats / and \ the same but a Windows user may be puzzled by this /)...

As Qt is a cross-platform toolkit and the whole world, except for Microsoft Windows, uses "/" as path separator rather than "\", internally all paths will use "/" as separator. I should convert the strings to "native separators" before displaying them to the user. And I think that's what I did in most places. If I forgot it in some places, it should be easy to fix.

Then all the frills of the QT like blue bars around text boxes, making a dotted rectangle around the buttons that are default (the OK for example if it's the only button on dialogue)... it all makes the interface "bad" for regular users...

Again that's Theme-specific. I personally like the "Plastique" style. But if you prefer "Cleanlooks" or a native "Windows" look, you can switch the theme at any time.

(LameXP will remember the selected theme for next startup)

EDIT: Maybe I should start a poll and let the users vote which style they like best. Then I can make that style the default one and nobody can complain :D

mariush

23rd January 2011, 18:28

LoRd_MuldeR

23rd January 2011, 19:21

re: folder in 8.3 notation, see:

http://msdn.microsoft.com/en-us/library/aa364980%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/aa364963%28v=VS.85%29.aspx

Feeding a long path to these functions won't do any harm, so no matter what path you'd give them, you'd receive the long nice path in return.

I know about these functions.

But if I only deal with "long" and fully-qualified path names all the way, and that's what I do, there is no need to explicitly convert to "long" names.

The only way how a "short" name can slip into the application is by explicitly calling the executable with a "short" path name (as WinRAR probably did). And then you'll get what you have requested.

I don't think that is a case we should worry about. Normally the user will launch the application from Explorer or Startmenu and then it get's called with a "long" path name.

re slow load: you can't ask users to disable the antivirus software to load the app fast, and considering most users will have some sort of antivirus installed you should work around it, not users around your app.

Sure, we can't request people to turn off the Anti-Virus software. Still what my application does is legitimate work and an Anti-Virus software is supposed to not impair legitimate actions of legitimate applications! So this certainly is not something that I'm supposed to fix on my side. It's something they are supposed to fix on their side. As soon as legitimate software needs to implement workarounds against bothersome Anti-Virus software, something is seriously wrong. Consequently while people shouldn't turn off their Anti-Virus software, the should report the problem to the A/V vendor. And if the A/V vendor doesn't fix the problem, they should switch to another product. If nobody complains about slow Anti-Virus software, the developers of these products will think that it's no worth to spend any resources on speed-optimizations...

re theme: i completely understand but as I said... consistency and everything

For "consistency" you can switch to one of the native Windows themes at any time. The "Classic" style gives you consistency to Windows 2000, even under Windows 7. That's as much consistency as you can have (except if you want consistency to MS-DOS or Windows 3.11 ^^). Still I doubt that the average user cares about consistency that much. Compared to the fancy user-interfaces you see in many popular applications (just think of Skype/YM! or the infamous "Ribbon" interface of MS Office 2007 ^^) even the "Plastique" style of Qt still is extremely conservative.

re license : if you aim to make the zip version "portable" then it shouldn't touch the disk in any location other than the default temporary folder specified by the operating system. Users who don't wish to "install" something obviously don't want to create files in various locations (application data for example) or may not have the rights to create files there.

LameXP doesn't create files in any location, except for the system directories that are intended for exactly that purpose. So temporary files go to the %TEMP% folder and configuration files go to the %APPDATA% folder, as intended. Storing configuration files in the same location where the EXE file is located is not an option, as the EXE file quite often will be located in "C:\Program Files (x86)", where Non-Admin users don't have write access (with UAC even Admins don't have access there). But somewhere the configuration must be saved! However I will implement a workaround that allows LameXP to store/load the configuration file to/from the "EXE directory", if explicitly desired by the user. Re-naming "LameXP.exe" to something like "LameXP-Portable.exe" should be the easiest method. This might be useful for people who have the software on their USB stick and use it on different computers. Also in this case it will be up to the user to ensure that write access to the "EXE directory" is granted. Of course the installer will create files (shortcuts) in the Startmenu as well as on the Desktop and it also creates a few Registry entries, but that's what one expects from an installer. You can choose the ZIP package if you don't want that.

It should also not prohibit me from running the application again.. for example I start application, I see the license but I'm too tired today and I want to read the license tomorrow and understand it so I cancel the process and I see tomorrow that I'm no longer able to use the application because it saved the "no" answer in an .ini file somewhere on the disk without letting me know.

Right.

re license text: it's either full text or nothing - the full text is not required but it should either be a link to the license or the full license shown, not just a couple of paragraphs - user may understand by those paragraphs that those paragraphs are the full license and ignore the other terms of the license describe further, making it void.

Still, the GPL text says "If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program." Followed by exactly the text that I have attached to my program. Regardless of whether displaying this text to the user has legal meaning or not, it still is a valuable information that should be presented to any user at least once (and doing that at the first startup seems reasonable). For the rest, there already is a link to the full text.

A simple license.txt in the ZIP file would be actually enough, I believe. Virtualdub loads the full license text in a window using a text area with vertical scroll and only an OK button, then lets user decide if he wants to continue using the application or not, as there's no requirement for a user to accept the license

I will add the GPL as plain text file to the ZIP package and the installer. I just forgot about this.

(by continuing to use the software, it's an implied acceptance of the license):

from the GPL 2.0 license text:

The GPL 2 license, as far as I understand reading it, does not prohibit user from running the application. It only prohibits user from modifying and re-distributing it when certain conditions aren't met. Running application is neither modifying or re-distribution. So refusing user to run the application is silly if not above what the license requires.

Okay. But even if the GPL does not imply that the user has to agree to the license before using the software, my software "as-is" does ask the user to agree. And (according to the paragraph you have quoted) without agreeing to the license, the user is only allowed to use the software "as-is" (which in this particular case means including the license agreement dialog, as that is part of the software) but not to modify or redistribute it. If the user wanted to remove/skip the license agreement dialog, this would require a modification of the software. And for such modifications the license has to be agreed anyway...

LoRd_MuldeR

26th January 2011, 23:10

Beta-2 is out :)

This version contains a few minor improvements and completes the "Advanced Options" tab. The "normalization", "resampling" and "bass/treble adjustment" filters should be working now.

Furthermore this version introduces a "true" portable mode, which will keep the configuration (INI file) in the same folder where the EXE file is located.

In order to enable the "portable" mode, simply rename the 'LameXP.exe' to 'LameXP-Portable.exe'. However you have to make sure that the application folder is writable for non-elevated processes!

(Therefore using LameXP with "portable" mode from a location in 'C:\Program Files' or 'C:\Program Files (x86)' will not work correctly on Vista/Win7)

SeeMoreDigital

27th January 2011, 20:12

I'm lovin' it. Great work :)

LoRd_MuldeR

3rd February 2011, 14:11

Beta-3 is out :)

This version adds shell integration (explorer context menu) + support for additional input formats + ability to import playlist files.

I also created a poll, so people can vote for their favorite UI style now:
http://mulder.brhack.net/temp/style_poll/

(If enough people vote, I will the make the most popular UI style the new default style)

cengizhan

3rd February 2011, 22:18

LoRd_MuldeR

3rd February 2011, 22:38

i like your program but one thing. every time i open the program, in metatag tab i have to change position and comment to (not specified). please do not reset this settings with every run. why are not these settings saved?

I do not reset these settings. I simply do not save their current value on program exit ;)

That's because I consider the "Meta Data" fields as something that you'll have to update (re-enter) for every album/collection you convert anyway. If I would save these information, there is the danger that the user forgets to look at the "Meta Data" tab and thus some old and completely unrelated meta information that were saved from a previous encode long time ago will be embedded...

(BTW: I see you are from Turkey. Would you like to translate (http://mulder.brhack.net/public/doc/lamexp_translate.html) the software to Turkish language? ^^)

cengizhan

6th February 2011, 10:32

mariush

6th February 2011, 13:04

Mulder, I like the Cleanlooks design, except the dropdown list double arrow thing, which is easily confused with the up-down select thingie. I don't know if you can combine them but if you could it would be great.

LoRd_MuldeR

6th February 2011, 15:02

then can you set track field to (not specified) instead of generate from list position? also comment field from encoded with lamexp to blank? Because it overwrites previous comments.

I'm not planning to change the defaults for "Comment" and "Position" options.

However, in contrast to the other fields in the "Meta Data" tab, it might make sense to save/restore these two fields on program exit/launch.

So that will probably be the way to go...

And i can help to translate.

Nice. Then please see the LameXP translator's guide here:
http://mulder.brhack.net/public/doc/lamexp_translate.html

If you have any questions, feel free to PM me at any time...

Mulder, I like the Cleanlooks design, except the dropdown list double arrow thing, which is easily confused with the up-down select thingie. I don't know if you can combine them but if you could it would be great.

Sorry, that is not possible. The "style" is setup up globally, for the QApplication object. AFAIK you can't change the style for individual widgets (or individual widget classes).

I probably could create my own QStyle class, mixing aspects from QPlastiqueStyle and QCleanlooksStyle, but that's something I'm not currently planning...

(It would probably require digging into a lot of "low level" implementation details of Qt)

manolito

6th February 2011, 16:09

Just tried to test the current beta3, but no luck here...:confused:

I just get the debug console, CPU load stays at 90%, no other window appears. My system is WinXP SP3 with all current updates. I have full admin rights, and all compatibility options also make no difference. I do have a couple of VC++ redistributables installed (from 2005 to 2008).

Do I need to install some other libraries first? If so, could you provide download links for them?

Cheers
manolito

LoRd_MuldeR

6th February 2011, 16:20

I just get the debug console, CPU load stays at 90%, no other window appears.

It's normal and expected to the see the console window, as the console is enabled by default in all Beta builds (will be disabled by default in the "Final" version).

So what does the console say? At which point it stops proceeding?

And are you sure you aren't in "Mark" mode ("Edit -> Mark" or a simple left-click with QuickEdit enabled) in the console? As long as you are in "Mark" mode, the application will be frozen!

Also: In my experience poor "Anti Virus" software can slow-down the start-up process significantly! It's quite possible that you just have to wait a little longer...

(In my personal experience Avira Antivir is pretty fast, Microsoft Security Essentials is slower but still okay and NOD32 is slow like hell)

My system is WinXP SP3 with all current updates.

Windows XP with Service-Pack 3 is one of my test platforms. And I have not experienced any problems so far...

I have full admin rights, and all compatibility options also make no difference.

Please keep all compatibility options disabled. LameXP even would refuse to continue with compatibility mode enabled ;)

I do have a couple of VC++ redistributables installed (from 2005 to 2008).

Well, that's nice :p

But the pre-compiled LameXP binaries have been linked against the static MSVCR libraries, so you do not need to install the VC++ Redistributables.

(It certainly doesn't hurt to have them installed, but the pre-compiled LameXP binaries simply won't be effected)

Do I need to install some other libraries first? If so, could you provide download links for them?

Nope. The pre-compiled binaries of LameXP are fully self-contained and work "out-of-the-box".

All dependencies have been linked statically for maximum ease of use. Still you might want to verify this with Dependency Walker, if you don't trust me ;)

http://img94.imageshack.us/img94/8048/lamexpdepends.th.jpg (http://img94.imageshack.us/img94/8048/lamexpdepends.jpg)

nitinpushpan

6th February 2011, 16:34

Hi,
Firstly, Thank you for such a nice software. I've been using it for few days and I think it is one of the best audio encoding software. Secondly, I'd like to address an issue that I noticed. I'm not sure whether its only happening to me. I'm using v4.00 Beta-3 (Build 290) on Windows 7 Home Premium (x64). While encoding flac files to AAC using Nero AAC v1.5.4 (Quality level 0.50) I get an error and the log reads as follows:

The format of this file is NOT supported:
C:/Users/Nitin/Desktop/The Black Eyed Peas - 01 - The Time (The Dirty Bit).flac

Container Format:
Audio Format:

Now this happened when I disabled the option "Write meta information to encoded files" under the Meta Data tab. I works fine when it the option is enabled.

Keep up the good work!

LoRd_MuldeR

6th February 2011, 16:39

Hi,
Firstly, Thank you for such a nice software. I've been using it for few days and I think it is one of the best audio encoding software. Secondly, I'd like to address an issue that I noticed. I'm not sure whether its only happening to me. I'm using v4.00 Beta-3 (Build 290) on Windows 7 Home Premium (x64). While encoding flac files to AAC using Nero AAC v1.5.4 (Quality level 0.50) I get an error and the log reads as follows:

Now this happened when I disabled the option "Write meta information to encoded files" under the Meta Data tab. I works fine when it the option is enabled.

Keep up the good work!

I can reproduce the problem. Thank you for reporting this serious bug! I will look for a fix as soon as possible...

LoRd_MuldeR

6th February 2011, 18:31

I can reproduce the problem. Thank you for reporting this serious bug! I will look for a fix as soon as possible...

A new build is now available via auto-update. This (hopefully) fixes the issue :)

Can you please test with and without having "write meta tags" enabled? Can you also test with "write meta tags" enabled and having some custom tags specified on the "meta data" tab?

:thanks:

manolito

6th February 2011, 19:02

It's normal and expected to the see the console window, as the console is enabled by default in all Beta builds (will be disabled by default in the "Final" version).

So what does the console say? At which point it stops proceeding?

It stops right after the disclaimer. The last words are "ABSOLUTELY NO WARRANTY". After this there is a blinking cursor, and that's it.

And are you sure you aren't in "Mark" mode ("Edit -> Mark" or a simple left-click with QuickEdit enabled) in the console? As long as you are in "Mark" mode, the application will be frozen!

No, I am not in "Mark" mode. I tried each and every console option, no difference.

Also: In my experience poor "Anti Virus" software can slow-down the start-up process significantly! It's quite possible that you just have to wait a little longer...

(In my personal experience Avira Antivir is pretty fast, Microsoft Security Essentials is slower but still okay and NOD32 is slow like hell)

I do not have any of the usual resident AV scanners installed, they slow down my system too much. I use ThreatFire, and just to make sure that it is not to blame, I uninstalled it completely. No difference, though...

So far the only other time that a program window just refuses to appear on my system is the Windows version of Devede. It uses the Python GTK library, and it just won't run on my machine. But according to their forum I am not the only one. Maybe the Qt library does not like my system, too.

I should mention that my machine is quite ancient. My graphics card is an ATI Rage Pro Turbo AGP 2x, DX9 is installed, and according to DXDiag everything works without problems.

Cheers
manolito

LoRd_MuldeR

6th February 2011, 19:17

It stops right after the disclaimer. The last words are "ABSOLUTELY NO WARRANTY". After this there is a blinking cursor, and that's it.

Strange :confused:

Best solution, of course, would be debugging LameXP on your system. But if you don't know how to do that, I could send you a "special" build with more debugging output.

Maybe we could locate the exact line where it stops responding...

I do not have any of the usual resident AV scanners installed, they slow down my system too much. I use ThreatFire, and just to make sure that it is not to blame, I uninstalled it completely. No difference, though...

Indeed I had some trouble with ThreatFire myself.

It injects its own DLL into the address space of any running process, which reproducible caused MSYS to crash for me :rolleyes:

I assume you did a clean reboot after uninstalling ThreatFire?

So far the only other time that a program window just refuses to appear on my system is the Windows version of Devede. It uses the Python GTK library, and it just won't run on my machine. But according to their forum I am not the only one. Maybe the Qt library does not like my system, too.

Well, GTK+ and Qt both are cross-platform GUI frameworks. But that's it. They are two completely separate projects.

So your problems with Qt- and GTK+-based programs are most likely unrelated. However did you try other Qt-based software on your machine?

For example SMPlayer or Avidemux 2.5?

Also: Did you make a clean "format + re-install" of your system recently? This sometimes works wonders with "unexplainable" Windows bugs ;)

I should mention that my machine is quite ancient. My graphics card is an ATI Rage Pro Turbo AGP 2x, DX9 is installed, and according to DXDiag everything works without problems.

Qt fully supports Windows XP and it doesn't need any special 3D hardware. There is some support for OpenGL in Qt, but I don't use that in LameXP.

After all, LameXP works fine even on my Windows 2000 machine, although Windows 2000 is not officially supported by Qt 4.7. It even works under Linux/Wine.

http://img651.imageshack.us/img651/8990/screenshotwine.th.png (http://img651.imageshack.us/img651/8990/screenshotwine.png)

LoRd_MuldeR

8th February 2011, 01:35

Build #298 fixes a bug in the CPU detection code that could lead to an infinite loop on some systems. Thanks to manolito for the report!

(Unfortunately people who are effected by this bug will have to update manually, because the application will stall before auto-update gets a chance to run)

nitinpushpan

10th February 2011, 05:29

A new build is now available via auto-update. This (hopefully) fixes the issue :)

Can you please test with and without having "write meta tags" enabled? Can you also test with "write meta tags" enabled and having some custom tags specified on the "meta data" tab?

:thanks:

Sorry for the late reply. It works fine now with and without "write meta tags" enabled and with custom tabs specified. I'm using the v4.00 Beta-4, Build 300 [2011-02-09].

I'd like to make 2 suggestions also.

It would be nice if the entire tags from the source file got copied to the encoded file (Like the album art, album artist, composer, etc.).
I would like to Normalize the files to the peak volume of 0 db please. I'm not sure why you have restricted it to -0.50 db.

:thanks:

LoRd_MuldeR

10th February 2011, 10:30

Sorry for the late reply. It works fine now with and without "write meta tags" enabled and with custom tabs specified. I'm using the v4.00 Beta-4, Build 300 [2011-02-09].

Good to know :)

I'd like to make 2 suggestions also.

It would be nice if the entire tags from the source file got copied to the encoded file (Like the album art, album artist, composer, etc.).
I would like to Normalize the files to the peak volume of 0 db please. I'm not sure why you have restricted it to -0.50 db.

1. I can only copy (re-embed) tags that (a) MediaInfo retrieves from the original input file and (b) the individual encoder (e.g. LAME) can embed. It seems LAME can embed "album art" (jpeg/png/gif file, 128KB max), but I don't know of an easy way to extract the "art" from the original input. Moreover I never understood why people want to have JPEG/PNG's stored in their audio files, especially when it's the very same picture stored redundantly in all files of the album. Why not simply put the cover image as a separate JPEG/PNG file into the album folder once? I guess this is some kind of useless "iPod" gimmick...

2. Normalization is restricted to -0.5 db in order to protect against clipping. I think pushing the normalization up to the maximum amplitude isn't a good idea.

nitinpushpan

10th February 2011, 12:50

I totally agree with you on the iPod gimmick part. Unfortunately this gimmick is now followed by most of the companies. Honestly I really never care for the album art before but now it really bugs me out when I see a stupid headphone symbol or an empty square in my pmp. I usually don't add the entire album to my pmp so I add album art to each of the files. Its like they have enforced something cool which we really never cared for in the first place.

And about Normalization, by definition, applies a constant gain to the selected part or the entire track without exceeding 0.0 dBFS, or 100% (0 dB). For example in Audacity, it analyses the track for the peak amplitude and then applies the normalization filter ensuring that this peak amplitude does not cross 0 dB, hence no clipping.

mariush

10th February 2011, 12:53

Mulder, images should be embedded in an ID3v2 tag, so you should be able to read and write them relatively easily: http://www.id3.org/Developer_Information The link has plenty of information and I think there's even a GPL library that reads and writes id3v2 tags easily so you don't have to reinvent the wheel.

LoRd_MuldeR

10th February 2011, 13:58

And about Normalization, by definition, applies a constant gain to the selected part or the entire track without exceeding 0.0 dBFS, or 100% (0 dB). For example in Audacity, it analyses the track for the peak amplitude and then applies the normalization filter ensuring that this peak amplitude does not cross 0 dB, hence no clipping.

"If you’re planning to put normalized audio on CD, you might want to normalize the waveforms to no more than 96% as some audio compact disc players have problems accurately reproducing bits that have been processed to 100% (maximum) amplitude." – Cool Edit Pro (predecessor of Adobe Audition) manual

"Specifically, normalization applies a constant amount of gain to the selected region of the recording to bring the highest peak to a target level, usually to -1.0, or to -6.0 dB, in order to allow for addition of two channels without exceeding 0.0 dBFS, or 100% (0 dB)" – http://en.wikipedia.org/wiki/Audio_normalization

Mulder, images should be embedded in an ID3v2 tag, so you should be able to read and write them relatively easily: http://www.id3.org/Developer_Information The link has plenty of information and I think there's even a GPL library that reads and writes id3v2 tags easily so you don't have to reinvent the wheel.

Well, they are embedded in an ID3v2 Tag for MP3 files. The problem is that I have to support various input formats (MP3 is only one of them) as well as several encoders. So I would need to find a method that can detect/extract the "album art" from all supported input formats (or at least from those, that potentially contain "album art" of some kind). Moreover the "album art" would have to be extracted in a format that can be accepted for embedding by all supported encoders. Implementing a separate path for each "input format + encoder" combination won't be possible to accomplish with reasonable effort...

johnsonlam

10th February 2011, 20:18

Great! Thanks!
Glad to know a lot of improvements in the new version!

LoRd_MuldeR

13th February 2011, 01:02

RC-1 is out :)

This is the first release candidate. The final v4.00 release is scheduled for 2011-02-20.

If you have any showstoppers to report, please do now ;)

mariush

17th February 2011, 22:38

LoRd_MuldeR

18th February 2011, 01:14

Stumbled on some bug when updating from 290 (or maybe 268...i'm not sure) something to 316, went check for updates, download, next and then the wma thing kept popping from behind and I couldn't close LameXP due to that, had to close it using Process Explorer (yeah task manager would have worked too).

See http://www.youtube.com/watch?v=_xKTDJs9TCk

note that window saying "Download failed" but I never selected to download and installed the wma codecs/tools.

Thanks for the report :)

I was able to reproduce the issue: It only happened when the auto-updater was launched by the update-reminder (i.e. not manually by the user) and a new update was available and the user chose to install the update and the WMA decoder component was not installed on the computer yet. I think I found the reason for this mess and it should be fixed by now in build #320. At least I hope so...

:thanks:

manolito

20th February 2011, 00:12

Hi MuldeR,

had some time today and gave Build #320 an extensive test run.
Results: Uneventful...:) Everything works as expected, absolutely stable.

Still I wish you had found the time to add AC3 output to LameXP. A complete rewrite would have been the perfect occasion. ;)

And I also found the time to explore a real bug which had already been present in v. 3.18. Remember my old post?

Quote:Originally Posted by manolito
And now my question which concerns AC3 to WAV conversion:
Whenever I convert a 2-channel AC3 to WAV with LameXP, this WAV file plays OK in MPC, WaveLab also has no problems with it. But when I try to use this file with MuxMan to author a DVD, MuxMan rejects the file.

Might be a WAVE_FORMAT_PCM -vs- WAVE_FORMAT_EXTENSIBLE issue. See for details:
http://www.microsoft.com/whdc/device...ultichaud.mspx

Anyway, I think mpucoder would be the man to ask about MuxMan issues...

No, it has nothing to do with the EXTENSIBLE format. I googled the specs, bytes 21 and 22 in the header would clearly indicate the extensible format, and this is not the case here. And it certainly is not a MuxMan issue. When MuxMan rejects a file then you can be 100% sure that this file has a compatibility problem. Period.

The error only happens when the source is AC3, when the source is MP3 everything is fine.

Scenario:

Source is a 2-channel AC3 file, 48 kHz sampling rate, 16 bit.
(Just to make sure that the error is not with the source, I used a couple of different source files created either with Aften or with AC3Enc)

My goal was to convert the AC3 to a Wave file with the same depth and sampling rate.

Load the AC3 into LameXP, select WAVE as output format, under advanced options leave sampling rate on "Automatic".
Resulting file is 48 kHz 16 bit WAVE, and it is rejected by MuxMan.

Second test: Same source file, the only difference is that under advanced I set the sampling rate to 48 kHz instead of automatic. Resulting file is also 48 kHz 16 bit Wave, but this time MuxMan accepts it. Open the two files in a hex editor and notice that they have very different headers.

These two files should be bit by bit identical. Why aren't they? The fact that MuxMan refuses to open the file which was created with the "automatic" sample rate setting is enough to tell me that the header of this file is corrupt.

I hope you can fix this without delaying the final release too much...:p

Cheers
manolito

LoRd_MuldeR

20th February 2011, 15:03

had some time today and gave Build #320 an extensive test run.
Results: Uneventful...:) Everything works as expected, absolutely stable.

Still I wish you had found the time to add AC3 output to LameXP. A complete rewrite would have been the perfect occasion. ;)

Maybe in the next release (I know that I said this before ^^).

I won't add new features right before the 4.00 release, so translators can finish up their work...

And I also found the time to explore a real bug which had already been present in v. 3.18. Remember my old post?

No, it has nothing to do with the EXTENSIBLE format. I googled the specs, bytes 21 and 22 in the header would clearly indicate the extensible format, and this is not the case here. And it certainly is not a MuxMan issue. When MuxMan rejects a file then you can be 100% sure that this file has a compatibility problem. Period.

How can you be so sure about it? I don't think MuxMan is the offical reference application for the Wave/RIFF format :p

As long as MuxMan is really the only application that complains, I would suspect the problem there...

The error only happens when the source is AC3, when the source is MP3 everything is fine.

Scenario:

Source is a 2-channel AC3 file, 48 kHz sampling rate, 16 bit.
(Just to make sure that the error is not with the source, I used a couple of different source files created either with Aften or with AC3Enc)

My goal was to convert the AC3 to a Wave file with the same depth and sampling rate.

Load the AC3 into LameXP, select WAVE as output format, under advanced options leave sampling rate on "Automatic".
Resulting file is 48 kHz 16 bit WAVE, and it is rejected by MuxMan.

So MuxMan obviously doesn't like the Wave/RIFF files created by ValibDec from AC3FilterTools (the AC3/DTS decoder used by LameXP).

But that doesn't necessarily mean that there is a problem with those files. It needs further investigation...

Second test: Same source file, the only difference is that under advanced I set the sampling rate to 48 kHz instead of automatic. Resulting file is also 48 kHz 16 bit Wave, but this time MuxMan accepts it. Open the two files in a hex editor and notice that they have very different headers.

Well, enabling the "Resampling" filter means that the decoded Wave file will be piped through SoX at least once, regardless of whether the new sample rate is identical to the input or not.

Obviously MuxMan likes the Wave/RIFF files written by SoX better.

These two files should be bit by bit identical. Why aren't they? The fact that MuxMan refuses to open the file which was created with the "automatic" sample rate setting is enough to tell me that the header of this file is corrupt.

I don't know what the difference between the Wave files written by ValibDec and those written by SoX is.

But just because one single application (i.e. MuxMan) refuses the files written by ValibDec, this doesn't necessarily mean that ValibDec's files are corrupt.

I will have a look, but can't grantee anything. In case it turns out ValibDec really writes invalid files, the AC3Filter developer would need to fix it...

manolito

20th February 2011, 16:44

How can you be so sure about it? I don't think MuxMan is the offical reference application for the Wave/RIFF format :p
Well, IMO you can look at MuxMan as the Ultimate unofficial DVD compliance checker.

Another strong indication that ValibDec is to blame is that if you open and resave these problematic files in a wave editor (I tried WaveLab, Nero Wave Editor and Audacity), MuxMan has no problems with the resaved files.

Cheers
manolito

LoRd_MuldeR

20th February 2011, 16:57

Well, IMO you can look at MuxMan as the Ultimate unofficial DVD compliance checker.

That doesn't matter. Wave files can't be DVD compliant, or not DVD complaint. That's because there's no such thing as a Wave file on a Video-DVD ;)

Whether the DVD authoring software accepts a specific Wave/RIFF file or not is a complete different question. And it has nothing to do with "DVD compliance".

It's the actual PCM audio data - may it be stored in a Wave container or in some other container - that can be DVD compliant (or not) in this case.

Another strong indication that ValibDec is to blame is that if you open and resave these problematic files in a wave editor (I tried WaveLab, Nero Wave Editor and Audacity), MuxMan has no problems with the resaved files.

That's not a proof that anything with the Wave files written by the ValibDec tool is wrong. Tough it doesn't indicate the opposite either.

I will try to have a look. Please give me a moment...

LoRd_MuldeR

20th February 2011, 18:08

manolito,

I can reproduce your issue. MuxMan rejects the Wave file written by ValibDec, but piping the file through SoX once makes it accept the file.

Unfortunately MuxMan doesn't give any information on WHY it did reject the file. Or do I miss something ???

Anyway, while it is obvious that the files are not bit-identical, I have so far been unable to find a reason that would justify accepting the one file, but rejecting the other.

All the analysis tools I tried seem to indicate that format of the files is identical:
http://pastie.org/private/n6uyrwqo3nqgihsjidyoa

Moreover I tried various applications (Audacity, CoolEdit Pro, Winamp, Foobar2000, MPlayer, VLC Player) and not a single one complained about the file written by ValibDec.

Last but not least encoding to FLAC from both Wave files individually results in two 100% bit-identical FLAC files. So the content is identical!

Consequently there currently is NO indication that there is anything wrong with the file. I will assume that this is a problem of MuxMan, unless more info is provided...

Taurus

20th February 2011, 21:00

@manolito
@LoRd_MuldeR

mano, I can feel the pain your in:p
Some time ago I tried to import wave files into Wavelab (famous wav editor).
They were rejected with some kind of stupid error message.
Loaded in any mediaplayer or other wav editors they were doing right.
So I fired up a hex editor to see the differences between Wavelabs angels and beasts.
There were definitly different header informations and rewriting the header
of the non working file solved the import failure in Wavelab.
Dont ask me how I solved it, it happened a long time ago in the past.
I changed my whole workflow since then.
Cant even remember the program or binary which wrote the wav's....

LoRd_MuldeR

20th February 2011, 21:20

manolito

20th February 2011, 21:25

I posted the issue to the MuxMan thread:
http://forum.doom9.org/showthread.php?p=1479439#post1479439

Let's see if mpucoder comes up with something....

Cheers
manolito

lethedoom

21st February 2011, 06:58

SeeMoreDigital

21st February 2011, 10:01

I posted the issue to the MuxMan thread:
http://forum.doom9.org/showthread.php?p=1479439#post1479439

Let's see if mpucoder comes up with something....In the meantime, you can always run your 2Ch PCM in .WAV files through WaveWizard ;)

Taurus

21st February 2011, 10:55

Again: You can't compare the Wave files byte-by-byte (e.g. in a Hex-Editor) and then conclude that one of the files is "broken", just because the files are different at some point.

Actually there may be various reasons why the files are different and still both files can be perfectly valid. The one and only thing that matters: Is the file "valid" with respect to the RIFF/Wave specifications?

If the file is valid with respect to the specifications, then the reading-application must accept it. And if it doesn't, then it's the reading-application (not the writing-application) that must be fixed.

Only if it turns out that the file is "invalid" with respect the the specifications, then the writing-application is to blame...

I just downloaded a Demo version of Wave Lab 5 and finally got it to work on my Windows XP VM. And it turns out that Wave Lab opens the Wave file written by ValibDec flawlessly
Sorry, if my post was a bit misleading.
I didn't assume that your program is writing wrong headers or content in wav files.
Wavelab 3.0 and 5.0 are opening the files made by your program just fine.
It was an older program (dont remember which one) which modified the header so wavelab could not read it.
Wavelab is the defacto standard for wav editing.
Just wanted to point it out that maybe the information in the header is bringing muxman to its knees.

LoRd_MuldeR

21st February 2011, 11:55

I have been using the 3.18 on my Windows intel core i5 cpu 650@3.2ghz pc and find it runs 8 threads simultaneously when encoding flac files to mp3. I tried the 4.0 build 324 today and it only ran 4 threads simultaneously and was obviously slower. When you release a final 4,0 stable version will it be similarly restricted to 4 threads ?

The number of parallel instances is limited, because running too many instances in parallel could easily result in HDD trashing and thus would actually slow down the process.

With Hexacore processors and Hyperthreading, PC's can have 12 or more (logical) cores nowadays. So I think we definitely need a limit here. Though four was chosen a bit arbitrarily.

LoRd_MuldeR

21st February 2011, 14:33

LameXP v4.00 Final has been released :)

Changes between v3.18 and v4.00:
* Complete re-write of LameXP in the C++ programming language
* Switched IDE from Delphi 7.0 to Visual Studio 2008 + Qt Framework v4.7.1 (GNU Toolchain not yet)
* Added cross-plattfrom support - only Windows and Wine for now, native Linux version planned
* Added full Unicode support for file names, meta tags and translations (no more Codepage headaches!)
* Added support for Qt Linguist tool, which makes creating/updating translations much easier
* Added support for multiple user interface styles, including "Plastique" and "Cleanlooks" themes
* Added support for user-defined encoder parameters (please use with care!)
* Added support for a true "portable" mode, which will store the configuration in the program folder
* Added resampling filter for all encoders, based on SoX
* Added simple tone adjustment filter, based on SoX
* Added an option to prepend the relative source file path to the output file path
* Updated all command-line tools to support Unicode file names, mostly required custom patches
* Updated LAME encoder to v3.99.0.11 (2011-02-11), compiled with ICL 11.1.065
* Updated OggEnc v2.87 using libvorbis v1.3.2 (2010-11-06), compiled with ICL 11.1 and MSVC 9.0
* Updated mpg123 decoder to v1.13.2 (2011-02-19), compiled with GCC 4.5.2
* Updated MediaInfo to v0.7.41 (2011-01-24), compiled with ICL 11.1.065
* Updated SoX to v14.3.1 (2010-04-11), compiled with MSVC 9.0
* Updated GnuPG to v1.4.11, compiled with GCC 4.5.2
* Updated language files (big "thank you" to all contributors !!!)
* Removed TAK support for now, as their CloseSource(!) tools don't support Unicode file names yet
* Removed Volumax tool, as we are using SoX for normalization from now on
* Countless minor fixes and improvements (hopefully not too many regressions ^^)

SeeMoreDigital

21st February 2011, 16:41

Many thanks... I've just downloaded it :)

Taurus

21st February 2011, 16:58

Many thanks... I've just downloaded it :):p

tipsypenguin

21st February 2011, 18:36

for some reason my antivirus is blocking tool_flac.exe as Suspicious.MH690.A every time I start LameXP

LoRd_MuldeR

21st February 2011, 19:30

for some reason my antivirus is blocking tool_flac.exe as Suspicious.MH690.A every time I start LameXP

Please check the file again at http://www.virustotal.com/, just to be sure, and then report the FALSE POSITIVE to the developer of the a/v software.

lethedoom

21st February 2011, 19:48

Thank you for this excellent free tool--you are my benefactor.

I see no reason to choose to use the slower 4.0 ( I did install and try the final version today ) when I have had no problems at all using the much faster 3.18--the same resources are used (100% cpu) and no hard drive problems ever occurred on my pc while using 3.18 running 8 simultaneous processes. As I am just a pedestrian computer user--neither expert nor a programmer--your arbitrary limit makes no sense to me in light of my usage experience.

LoRd_MuldeR

21st February 2011, 20:22

I see no reason to choose to use the slower 4.0 ( I did install and try the final version today ) when I have had no problems at all using the much faster 3.18--the same resources are used (100% cpu) and no hard drive problems ever occurred on my pc while using 3.18 running 8 simultaneous processes. As I am just a pedestrian computer user--neither expert nor a programmer--your arbitrary limit makes no sense to me in light of my usage experience.

I do not have a machine with more than 4 cores available for testing. And I doubt there currently are many users that do ;)

While I still doubt that running zillions of instances in parallel is a very good idea, I can add an option to configure the maximum number of instances in one of the future versions...

manolito

21st February 2011, 21:01

Latest findings about these funny Wave files created by ValibDec:

I just downloaded a Demo version of Wave Lab 5 and finally got it to work on my Windows XP VM. And it turns out that Wave Lab opens the Wave file written by ValibDec flawlessly
I never said otherwise. See my previous posts:
And now my question which concerns AC3 to WAV conversion:
Whenever I convert a 2-channel AC3 to WAV with LameXP, this WAV file plays OK in MPC, WaveLab also has no problems with it. But when I try to use this file with MuxMan to author a DVD, MuxMan rejects the file.
Another strong indication that ValibDec is to blame is that if you open and resave these problematic files in a wave editor (I tried WaveLab, Nero Wave Editor and Audacity), MuxMan has no problems with the resaved files.

In the meantime I found that two other audio converters I frequently use also reject these Wave files:

BeLight 0.2.2.0 (this is the latest version) by Kurtnoise simply refuses to load the file without any error message.

HeadAC3he 0.24 a13 by Dark Avenger also does not accept these files. But it displays the following error message: "Could not find fmt chunk!"

I also found an old app called StripWav which can strip extra information from a Wave file header and convert the header to the "canonical" format. This app determines: "Extra chunks: JUNK". Needless to say that the stripped file does work with MuxMan, BeLight and HeadAC3he.

My conclusion: Even if these files created by ValibDec may not be technically illegal, they certainly have a very unusual header leading to an incompatibility with a couple of other applications.

Cheers
manolito

LoRd_MuldeR

21st February 2011, 21:58

HeadAC3he 0.24 a13 by Dark Avenger also does not accept these files. But it displays the following error message: "Could not find fmt chunk!"

I also found an old app called StripWav which can strip extra information from a Wave file header and convert the header to the "canonical" format. This app determines: "Extra chunks: JUNK".

Well, I can confirm that the Wave file written by ValibDec contains a 'JUNK' chunk before the 'fmt' chunk. The file that has been piped through SoX (and is accepted by MuxMan) does not ;)

However this is not "unusual" at all: RIFF files often contain 'JUNK' chunks for padding. And, by definition of the RIFF format, a reading application must ignore/skip all the 'JUNK' chunks that it encounters!

Some applications might not implement a real RIFF parser and instead expect the 'fmt' chunk ("Wave header") to be located at a hard-coded position; may it be for simplicity, laziness or nescience.

But it is obvious that such applications are prone to fail on certain valid RIFF/Wave files. Consequently I think we really can't/shouldn't blame the writing application here...

Taurus

21st February 2011, 22:10

I also found an old app called StripWav which can strip extra information from a Wave file header and convert the header to the "canonical" format. This app determines: "Extra chunks: JUNK". Needless to say that the stripped file does work with MuxMan, BeLight and HeadAC3he.

Thank you for this suggestion, something for my audio toolbox...:p

lethedoom

21st February 2011, 23:34

I do not have a machine with more than 4 cores available for testing. And I doubt there currently are many users that do ;)

While I still doubt that running zillions of instances in parallel is a very good idea, I can add an option to configure the maximum number of instances in one of the future versions...

I will be grateful when you do that. When any version of LameXP is running and using up the available cpu capacity on my pc the cpu core temperatures rise. The slower 4.0 iteration of LameXP exposes the cpu cores and mainboard to the elevated temperature for a longer time which I surmise is undesirable in regard to maximizing their useful lifetimes. My pc is only dual core, but it also creates two virtual cores and each of the four cores runs two processes totalling eight concurrently using 3.18. That is what I would want 4.0 to do as well.

mariush

21st February 2011, 23:53

lethedoom you don't have to worry about that... both the motherboard and the cpu are designed to work at elevated temperatures for a long time, it really won't make a difference to their lives whether the cpu warms up the components or not. In fact it's better to keep the cpu at a higher yet steady temperature rather than just oscillate between cold and warmer cycles.

But it's all statistical anyway, the "life" of a cpu will drop due to temperature cycles from a few million hours to a few million hours - a few thousand - the difference is so small your cpu would be antique before it dies.

ps. The majority of components sensitive to heat on a motheboard (capacitors) are rated 85-105 C - so in order for a motherboard to fail, the temperature inside your computer case would have to be around 60-70C for days (capacitors get "older" faster as temperature is closer to their highest rating) in order to weaken these components. At the normal 30-40C temperature inside the case, these last for at least 5-10 years. By that time, you'll probably change several computers.

LoRd_MuldeR

21st February 2011, 23:58

I will be grateful when you do that. When any version of LameXP is running and using up the available cpu capacity on my pc the cpu core temperatures rise. The slower 4.0 iteration of LameXP exposes the cpu cores and mainboard to the elevated temperature for a longer time which I surmise is undesirable in regard to maximizing their useful lifetimes.

Now that is nonsense, really ;)

I've got my Intel Q6600 for more than four years now. And this machine is running like 8-12 hours every single day. I also use this machine for video encoding, so often the CPU's is running with 100% load on all four cores for several hours! That all is with the crappy "boxed" cooler. And, as you can see, I'm still online. So the machine has not exploded yet.

Moreover, running more instances in parallel in order to increase the CPU load would produce even more heat. So with your argumentation this would be the exact opposite of what you want...

My pc is only dual core, but it also creates two virtual cores and each of the four cores runs two processes totalling eight concurrently using 3.18. That is what I would want 4.0 to do as well.

That makes even less sense. If you really have a Dual Core processor (two physical cores), then even with Hyperthering enabled you have at most four (logical) cores available.

On such a machine running four instances in parallel is sufficient to fully utilize the CPU. Running even more instances than (logical) cores in parallel is pointless if not counterproductive.

lethedoom

22nd February 2011, 00:36

Now that is nonsense, really ;)

I've got my Intel Q6600 for more than four years now. And this machine is running like 8-12 hours every single day. I also use this machine for video encoding, so often the CPU's is running with 100% load on all four cores for several hours! That all is with the crappy "boxed" cooler. And, as you can see, I'm still online. So the machine has not exploded yet.

Moreover, running more instances in parallel in order to increase the CPU load would produce even more heat. So with your argumentation this would be the exact opposite of what you want...

That makes even less sense. If you really have a Dual Core processor (two physical cores), then even with Hyperthering enabled you have at most four (logical) cores available.

On such a machine running four instances in parallel is sufficient to fully utilize the CPU. Running even more instances than (logical) cores in parallel is pointless if not counterproductive.

You are the expert, but nonetheless 3.18 accomplishes the job faster than 4.0 and does not drive core temperatures higher.

LoRd_MuldeR

22nd February 2011, 00:53

You are the expert, but nonetheless 3.18 accomplishes the job faster than 4.0 and does not drive core temperatures higher.

Did you actually stop the time? Or did you just look at the "CPU Utilization" in Task-manager?

Also: Are you 100% sure that you were using the same settings (rate-control mode + LAME algorithm quality) and the same input files for both versions?

Finally I don't think that the overall encoding process takes long enough to have a significant impact on the CPU temperature, unless you really process a huge number of files.

And even if the temperature did increase, you wouldn't have to worry, as the CPU is designed to run under full load for a long time.

If the CPU temperature ever reaches a "critical" level under load, then you should check whether the cooler in stalled correctly! Also cleaning the dust can work wonders ;)

(For clarification: Can you please post a screenshot of CPU-Z (http://www.cpuid.com/softwares/cpu-z.html) running on your computer?)

manolito

22nd February 2011, 01:44

LoRd_MuldeR

22nd February 2011, 02:13

Re problematic Wave files created by ValDec:

After some more research I believe I understand the problem now. The whole thing is about the RF64 Wave format extension which was introduced by the EBU around 2006.

This RF64 format is required if a Wave file gets bigger than 2GB. If an application writes a RF24 compatible Wave file, it inserts a JUNK chunk into the header. As long as the file size stays below 2 GB this JUNK chunk is just a placeholder and has no meaning, applications should ignore it. But if the size grows beyond the 2 GB limit, the RIFF header has to be replaced by a RF64 header which is bigger. This is why the JUNK chunk is needed.

But of course older software (pre 2006) has no knowledge of this JUNK chunk and often throws an error.

I just made some tests with WaveLab 6 which has an option to support the RF64 format (disabled by default). The results are pretty clear. With the RF64 option enabled it creates files which are not compatible with MuxMan, with the option disabled it produces compatible files.

Obviously ValDec always creates RF64 enabled Wave files, I have not found an option to turn this RF64 support off.

Maybe LameXP should have a checkbox "RF64 support" under the Wave output tab. If this checkbox is not checked then the output should always be piped through SoX.

Cheers
manolito

Well, this explains why the 'JUNK' chunk is inserted ;)

Still this "RF64" extension obviously was designed with backward-compatibility in mind. Therefore the additional information is stored inside a 'JUNK' chunk, which according to the RIFF specifications will be ignored/skipped by all "legacy" application, instead of modifying existing structures. So as long as the file size doesn't exceed a size of 4GB, legacy applications that don't support RF64 should still handle such files perfectly fine. And obviously most application do! Those that stumble upon the additional 'JUNK' chunk were broken from the beginning. Of course I could easily add an option to pipe the output Wave file through SoX. But somehow I dislike the idea of adding workarounds for specific third-party applications into LamXP, especially when the problem should actually be fixed on their side...

Actually ValibDec does NOT create RF64 Wave files, unless the file actually exceeds a size of 4 GB! It just inserts an empty 'JUNK' chunk at the beginning of the file as a placeholder. All compliant reading applications will later ignore that chunk. The placeholder is required, because if the file does exceed a size of 4 GB, then the 'ds64' chunk must be written to that location later on.

LoRd_MuldeR

22nd February 2011, 02:18

I spend a lot of time downloading Grateful Dead concerts from bittorrent sites...

Err...

http://forum.doom9.org/forum-rules.htm

:rolleyes:

manolito

22nd February 2011, 03:09

Actually ValibDec does NOT create RF64 Wave files, unless the file actually exceeds a size of 4 GB! It just inserts an empty 'JUNK' chunk at the beginning of the file as a placeholder.

This is exactly what I was saying:
Obviously ValDec always creates RF64 enabled Wave files

RF64 enabled means that as long as the file size is small enough it will have a RIFF header with an additional JUNK chunk so the header could be replaced later by a RF64 header.

Maybe there is another point I can make to push you in my direction...:D

LameXP is a front end for many different encoders and decoders to shield users from the various peculiarities of all these different tools. Shouldn't LameXP produce consistent output files regardless of the tools it uses in the background?

If I create a Wave file from an MP3 source, it will NOT be RF64 enabled, it does not have a JUNK chunk in its header. (I did not test other source formats, but I assume they also will not have this JUNK chunk). For any source format, if I enable the resampler (SoX), then the output Wave file will not have the JUNK chunk. Only if I happen to make a straight AC3 to WAV conversion using ValDec I get these files with a JUNK chunk in the header.

Anyways, it's your baby...:)

Cheers
manolito

lethedoom

22nd February 2011, 03:49

Err...

http://forum.doom9.org/forum-rules.htm

:rolleyes:

I'm not sure what you mean. per your request there is a better CPU Z image posted at

http://profile.imageshack.us/user/lethedoom

mariush

22nd February 2011, 04:11

http://code.google.com/p/ac3filter/source/browse/valib/sink/sink_wav.cpp?repo=valib

line 35. Add some parameter to switch between old style or new style wave file on creation and if old style is selected, then don't write the junk header in the first place? You already modified it to support unicode so why not add a command line switch like -format=auto,old,force-64bit etc...

Isn't the app aware or can't it compute the final length before it outputs the wav file to disk?

mariush

22nd February 2011, 04:40

lethedom : what he means is that it's against the rules to discuss or help people that ask for help in regard to pirated content. It's OK if you bought the DVD and wish to make backups but if you say something about downloading content without having rights to distribute it or process it, you may be banned as it's against the rules.

So getting back to your gpu-z picture. Your CPU is a i5 650 - that's dual core, but you can enable hyperthreading and have 4 cores (2 physical and 2 virtual). The two virtual cores will never be quite as fast as the real cores, as the cpu creates these two virtual cores by looking at how much each of the two real cores are loaded and then giving what the operating system assigned to a virtual core to the less used real core. Basically when a thread assigned to a real core doesn't have much to do for a few nanoseconds, the thread that was set by the operating system to run on a virtual core runs on this real core.

If you'd configure a program like x264.exe (which is very optimized for multithreading) to run with 2 threads encoding something at very high quality, you'll probably see that the 2 virtual cores won't be used much, because the real cores will have very little idle time and the cpu won't find the opportunity to run threads assigned to the virtual cores on the real cores.

This processor you have is designed to run each of those cores at minimum 3.2 Ghz and a maximum of 3.46 Ghz, depending on how much loaded they are. This processor is very powerful, so I would guess encoding an MP3 from a wav file would probably use about 15-20% of the cpu, maybe even less. This means that without even enabling those virtual cores, your processor could easily encode about 5 mp3 tracks at the same time, if the hard drive can keep up with reading 5 wav files from the disk at the same time.
When you enable hyperthreading, you add two virtual cores to the processor, which are not as powerful as the normal physical cores as I explained above, so I would guess these two virtual cores could add up about 30% of power, allowing you to encode an additional 2 mp3 files at the same time.

So in total, your processor and system could very well encode using eight threads (or eight individual files) or more and depending on the quality settings you use, maybe not even be 100% loaded, but your case is very particular - it's a very recent powerful cpu. Most people using dual core processors would have older processors that are not as powerful as yours and allowing 8 threads or more for dual core processors on those older systems would make the encoding very slow, because probably the hard disks on those systems wouldn't keep up.

I'm not sure if I've explained it right but I hope it helps.

mariush

22nd February 2011, 05:47

lethedoom

22nd February 2011, 06:15

thank you for the technical explanation.

Przemek_Sperling

22nd February 2011, 11:19

Thank you very much. Everything works great!

BTW, can anyone explain me why newer Ogg encoders produce significially larger files than the older ones? I compared files produced by LameXP 3.18, LameXP 4.00, and jetAudio 8.0.11. I encode music at Q8 (e.g. Mana - "Arde el Cielo - Vivo"). The sizes of the compressed CD are: LameXP 3.18 - 130 megabytes, LameXP 4.00 - 158 megabytes, and jetAudio 8.0.11.1600 - 159 megabytes.

tipsypenguin

22nd February 2011, 15:41

Please check the file again at http://www.virustotal.com/, just to be sure, and then report the FALSE POSITIVE to the developer of the a/v software.

I reported the false positive to Symantec and they are going to remove the detection from within their products . an update will be distributed in the next set of virus definitions.

Thanks for the new LameXP

LoRd_MuldeR

22nd February 2011, 20:44

Oh wow... hey, thanks i guess but no need to tell me, I'm not a mod or admin here. I just told you because I know the mods here are somewhat paranoid and start to ban people or close threads just for saying "torrent" or "downloaded" (even though he may have PURCHASED and downloaded and wants to re-encode for his own backup).

If he had purchased the stuff, he wouldn't download it "from bittorrent sites". Nor does this sound like he tries to make a backup ;)

Also this has nothing do with "paranoia". This forum has clear rules that all users accept when signing up. And the job of the moderators is to uphold these rules.

The sensitivity for "warez" is high, yes. And that's for good reason. We don't want that the people who are running this board get into serious trouble!

But if a user thinks his post/thread was removed/closed for no good reason, then he can always send a PM to the moderator in order to clarify the situation...

http://code.google.com/p/ac3filter/source/browse/valib/sink/sink_wav.cpp?repo=valib

line 35. Add some parameter to switch between old style or new style wave file on creation and if old style is selected, then don't write the junk header in the first place? You already modified it to support unicode so why not add a command line switch like -format=auto,old,force-64bit etc...

Isn't the app aware or can't it compute the final length before it outputs the wav file to disk?

The decision between "old style" and "new style" (RF64) Wave files is done when the file is closed, because prior to that point the Wave writer can't know if the final size will be above 4 GB or not.

In any case the 'JUNK' chunk has to be written at the beginning of the file, because we must be prepared for writing the "ds64" chunk later, if necessarily.

And to make this clear again: When the final size is below 4 GB, then ValibDec writes a perfectly valid RIFF/Wave file. The 'JUNK' chuck doesn't matter, as all reading application must ignore that chunk.

It is evident that that applications which fail to read the Wave file just because of the additional 'JUNK' chunk are broken!

Consequently the one and only question here is: Do we care enough about these broken applications to implement a workaround? Or should we encourage the authors to fix their RIFF/Wave parsers?

(If we modified the Wave writer to not write the 'JUNK' chunk, we couldn't turn the file into a RF64 file later anymore, which means we would kill support for output files larger than 4 GB)

I reported the false positive to Symantec and they are going to remove the detection from within their products . an update will be distributed in the next set of virus definitions.

Thanks for the new LameXP

Well done :thanks:

BTW, can anyone explain me why newer Ogg encoders produce significially larger files than the older ones? I compared files produced by LameXP 3.18, LameXP 4.00, and jetAudio 8.0.11. I encode music at Q8 (e.g. Mana - "Arde el Cielo - Vivo"). The sizes of the compressed CD are: LameXP 3.18 - 130 megabytes, LameXP 4.00 - 158 megabytes, and jetAudio 8.0.11.1600 - 159 megabytes.

Well, I assume you are using the "quality-based" (VBR) rate-control mode, as with the "bitrate-based" (ABR) mode the resulting file size would be defined solely by the chosen target bitrate.

The differing output sizes with VBR mode can be explained by different versions of OggEnc (libvorbis) being used. However comparing only the file sizes between the different versions doesn't tell you anything!

Instead you would have to adjust the VBR values, until both files have the same file size again. Then (and only then) you can compare the sound quality and decide which version is better...

(Alternatively you could adjust the VBR values until both files have the same sound quality and then compare the files sizes. But that's probably hard to do ^^)

mariush

22nd February 2011, 21:49

LoRd_MuldeR

22nd February 2011, 22:32

What I'm saying is that since you're modifying that tool to add Unicode support, you could in theory add a switch in the command line options (or some way to pass this to the tool, not sure how your app interacts with it), so that the tool will "TRUST" you that the output wav file will NOT exceed 4 GB or whatever the limit is. If the flag/switch in the command line is missing, just work like it works now. You should be able to determine based on number of seconds and channels the mp3/ac3/etc how much data you will have so you could pass this switch safely for files you know they won't reach that limit.

So if you pass that flag, let's say "-force-old-wav", the wav output class/whatever stores it, does not write the junk bytes at all and when closing the file, if the actual data is larger that what's allowed, enter the maximum allowed.

If total length and data is smaller than the limit for the format, it will play on all software, no junk, no ds64 chunk
if total lenght and data is larger, it will still play on all software, no junk or ds64 chunk but the data in the header will record the maximum number of samples allowed (basically truncating everything over max samples). So the rest of the data in the wav file would be ignored by players (not sure, maybe you'd need to seek to the end of the maximum samples and write there the ending for the chunk).

Yes, it should be possible to add such an option.

Still that option would only be helpful as a workaround for broken reading applications, which do not handle the 'JUNK' chunk as they are supposed to :devil:

Fortunately most applications are not broken in this regard. So I currently think this wouldn't be worth the effort.

Especially when considering that, in case you really encounter one of the broken applications, the solution is very easy: Re-save the file with SoX once and that's it.

Probably I will add a short note about this issue to the F.A.Q. document and then let the matter rest... Done!

mpucoder

22nd February 2011, 22:50

Now that I am aware of the reason for the junk chunk prior to the fmt chunk I'll begin modifying versions of MuxMan starting with the Pro version, then back-stitched to the free version.

manolito

23rd February 2011, 00:21

@mpucoder,

thank you very much, looking forward to the new version...

Cheers
manolito

ckmox

23rd February 2011, 07:38

thanks a lot for the final release :)

IgorC

24th February 2011, 00:48

LoRd_MuldeR

24th February 2011, 01:05

Any particular reason for including unstable alpha to supposedly stable and final GUI?

LAME 3.99a is on heavy alpha development and far from any beta release right now. It's untested.
No warning or any message for user? No choice between stable 3.98.4/unstable 3.99?

A huge thanks for the final release.

I need to use LAME v3.99, because that versions handles Unicode file names and Unicode tags on the Windows platform. The older 3.98 version did not...

olnima

24th February 2011, 10:56

But - are there any reasons against a manual update to 3.99a13?

Two steps nearer to first beta...

Thanks for LameXP,
Olnima

LoRd_MuldeR

24th February 2011, 12:14

But - are there any reasons against a manual update to 3.99a13?

Two steps nearer to first beta...

Thanks for LameXP,
Olnima

The last time I checked (before the LameXP v4.00 release), the latest tag in LAME's CVS repository was "lame3_99alpha11". Consequently that was the version I built. I just checked again and there is a "lame3_99alpha12" tag now (and HEAD is developed as 3.99a13 currently). But since my time machine is currently out of order, I will update to the latest LAME tag in the next LameXP release version.

IgorC

24th February 2011, 12:37

about LAME 3.99 alpha
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=79682&view=findpost&p=744961

since alpha_12 newer --vbr--new is set by default.
Last alpha 13 is here http://www.rarewares.org

btw, Mulder, if you are interested there is a new version of Aotuv Vorbis with a lot of tunings.

LoRd_MuldeR

24th February 2011, 12:46

btw, Mulder, if you are interested there is a new version of Aotuv Vorbis with a lot of tunes.

Already included:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=commit;h=442ff4095d69340a61b78f85ee3c5d3e5b563617

IgorC

24th February 2011, 12:52

Wow, that was fast.

There was important bugfix 6.01.

LoRd_MuldeR

24th February 2011, 14:56

New snapshot available:
http://sourceforge.net/projects/lamexp/files/Snapshots (BETA)/2011-02-25/

IgorC

25th February 2011, 05:08

Great, thank you for fast updates.

olnima

25th February 2011, 13:41

The last time I checked (before the LameXP v4.00 release), the latest tag in LAME's CVS repository was "lame3_99alpha11". Consequently that was the version I built. I just checked again and there is a "lame3_99alpha12" tag now (and HEAD is developed as 3.99a13 currently). But since my time machine is currently out of order, I will update to the latest LAME tag in the next LameXP release version.

I meant, if the updating of lame.exe could be done by the users or if You have any reasons not to recommend this.
You do not need a time machine for that.

LoRd_MuldeR

25th February 2011, 14:02

I meant, if the updating of lame.exe could be done by the users or if You have any reasons not to recommend this.
You do not need a time machine for that.

Generally it wouldn't be a very good idea to encourage "Newbie" users to replace the built-in LAME encoder with an arbitrary build that hasn't been tested to cooperate with GUI properly. There are all kinds of problems that might occur. At the same time "Advanced" users who can't wait for the next update and who know what they are doing can make their own builds at any time (the advantage of OSS).

codres

25th February 2011, 14:12

Is there a setting in the new version to change the temp folder. Is default in C:\. In the older one i could change it quickly. But in this I must be blind or maybe is not implemented? Thanks for your efforts in the development.

LoRd_MuldeR

25th February 2011, 14:19

codres

25th February 2011, 15:28

That's too bad, I must downgrade then. I have under 1GB space on C. Also multithreading could be disabled?

LoRd_MuldeR

25th February 2011, 15:53

That's too bad, I must downgrade then. I have under 1GB space on C.

Then it's probably time to clean-up your system drive/partition ;)

You will run into all kinds of problems with low disk space on your system drive/partition (not only with LameXP!), that's for sure.

Anyway, I can add an option to manually choose the directory for TEMP files...

Also multithreading could be disabled?

Not sure what you mean. But I recently added an option to manually overwrite the number of parallel instances (available in the latest snapshot build).

Settings this option to "1" effectively disables multi-threading, at least on the "batch processing" level. Although this usually isn't recommended...

codres

25th February 2011, 19:19

Well, usually my comp also encodes x264 most of the times. So I don't want to stress too much with mp3 encodings. So, yes, I want to use only 1 core. Thanks for the tips. Right now I have 1.3 Gb free on C which usually is enough but for a movie of 2h30 min gave me an error.

codres

27th February 2011, 06:45

Thanks for the new implementions! They work great mr. mulder :)

LoRd_MuldeR

28th February 2011, 19:07

Yet another aoTuV Beta-6 update ;)

aoTuV Beta6.02 [beta6.01 >> beta6.02] (2011/02/27)
# In the specific pattern (different from beta6.01), the bug that caused overflow was fixed.

John_J

6th March 2011, 22:36

Hello LoRd_MuldeR!

After a fresh reinstall of Windows XP, I also wanted to use LameXP again for my audio encodings and saw your update to v4.0.
First, I want to say that this new version became excellent...same simple workflow as before, but a brilliant new UI and nice updates.

I've played around in different ways and wondered myself where all extracted tool files have gone, because I couldn't find them in default temporary folder. After a look at Avast (Realtime-Scan is very useful in more than one way ;) ), I found them in "\Documents and Settings\USER\Local Settings\App Data\Temp".
You've stated (http://forum.doom9.org/showthread.php?p=1473735#post1473735) that temporary files go to the %TEMP% folder, but this folder is usually found at "\Documents and Settings\USER\Local Settings\Temp", isn't it? Or is this due to newer OS like Windows 7?

Regards,
JohnJ

EDIT: Forget above...looked at changelog of new beta build 350:

Changes between v4.00 and v4.01:

* Added an option to select a user-defined TEMP directory

Thanks!! :)

EDIT2:

Spoke too soon! It only affects folder of temporary audio files, so please have a look at it.

Gabrielgoc

7th March 2011, 00:26

LoRd_MuldeR, I was reading post #100 (http://forum.doom9.org/showthread.php?p=1473735 and I very interested about replaygain.

Replaygain main objective is not to adjust the volume without recompressing, but normalize the loudness based on the response of the human ear, so leave all the tracks on an even level. (http://en.wikipedia.org/wiki/Loudness). While replaygain is the most widely used algorithm, the EBU (European Broadcasting Union) has developed a new algorithm based on ITU-R BS.1770 as a loudness measurement method. This was standardized as EBU R-128. (http://tech.ebu.ch/loudness). If you are interested the following libraries can help you determine how to adjust the volume with SOX: http://www.hydrogenaudio.org/forums/index.php?showtopic=85978 and http://www.hydrogenaudio.org/forums/index.php?showtopic=86116.

I hope this info will be interesting to you. I apologize for my English. Greetings.

Gabriel

LoRd_MuldeR

7th March 2011, 11:38

I've played around in different ways and wondered myself where all extracted tool files have gone, because I couldn't find them in default temporary folder. After a look at Avast (Realtime-Scan is very useful in more than one way ;) ), I found them in "\Documents and Settings\USER\Local Settings\App Data\Temp".

You can also use ProcessMonitor (http://technet.microsoft.com/en-us/sysinternals/bb896645). Or look at the source code directly ;)

You've stated (http://forum.doom9.org/showthread.php?p=1473735#post1473735) that temporary files go to the %TEMP% folder, but this folder is usually found at "\Documents and Settings\USER\Local Settings\Temp", isn't it? Or is this due to newer OS like Windows 7?

The Windows operating system doesn't provide any API to detect the system's TEMP folder! Neither SHGetKnownFolderPath() nor SHGetFolderPath() knows about the TEMP folder. There is a function GetTempPath(), however this function does NOT return the path to the system's TEMP folder, but the current value of the %TMP% (or if that one isn't set %TEMP%) environment variable. Now %TMP% and %TEMP% will usually be set and they will usually point to the system's TEMP path, but they also may point to an arbitrary non-writable path or they may even contain complete garbage*! After all the environment variables are user-defined and may be screwed up. So it's something we better do not rely on! Question is: How do we detect the system's TEMP folder, if the Win32 API doesn't reveal it? Solution that works in practice: Obtain the path of the 'LocalAppData' folder (usually located at: "%USERPROFILE%\AppData\Local"), which is known to the Win32 API functions, and then simply append "\Temp" to that path. The result exactly matches the system's standard TEMP folder on Win7 (and probably Vista too), which is "C:\Users\John Doe\AppData\Local\Temp". It slightly differs from WindowsXP's default TEMP folder, but I see no problem there...

*from MSDN documentation: "Note that the function does not verify that the path exists, nor does it test to see if the current process has any kind of access rights to the path."

Spoke too soon! It only affects folder of temporary audio files, so please have a look at it.

That is exactly how it is intended. The "primary" Temp folder needs to be accessed even before user-settings have been loaded, so it cannot be user-controlled. However that shouldn't be an issue at all, as the amount of data extracted to that folder is really small. The user-controlled ("secondary") Temp folder will be used for all intermediate/temporary audio files during the encoding process. So that's the place where the "big" files will go to. Consequently users with a small system partition may want to change the location of the "secondary" Temp folder, while the location of the "primary" one shouldn't matter for anybody.

(If you don't have the ~10 MB of free space, that LameXP will occupy on start-up, available on your system partition, you will run into all kinds of problems with other applications too)

LoRd_MuldeR

7th March 2011, 12:03

Replaygain main objective is not to adjust the volume without recompressing, but normalize the loudness based on the response of the human ear, so leave all the tracks on an even level. (http://en.wikipedia.org/wiki/Loudness). While replaygain is the most widely used algorithm, the EBU (European Broadcasting Union) has developed a new algorithm based on ITU-R BS.1770 as a loudness measurement method. This was standardized as EBU R-128. (http://tech.ebu.ch/loudness). If you are interested the following libraries can help you determine how to adjust the volume with SOX: http://www.hydrogenaudio.org/forums/index.php?showtopic=85978 and http://www.hydrogenaudio.org/forums/index.php?showtopic=86116.

The "volume normalization" filter in LameXP already is implemented using the "gain" filter of SoX.

SoX also has a "--replay-gain" parameter, but apparently this can only be used to re-gain files that have already been tagged with ReplayGain information before.

From the SoX manual:
One important use of audio file comments is to convey ‘Replay Gain’ information. SoX supports applying Replay Gain information, but not generating it.

John_J

7th March 2011, 22:57

Hello LoRd_MuldeR,

thanks for your fast response!

You can also use ProcessMonitor (http://technet.microsoft.com/en-us/sysinternals/bb896645). Or look at the source code directly ;)

Yes, you're right :) ;) ...but Process Monitor isn't installed, yet (fresh installation).

BTW: Is this the right function which specifies temporary tool path?

Global.cpp

/*
* Get LameXP temp folder
*/
const QString &lamexp_temp_folder(void)
{
static const char *TEMP_STR = "Temp";

if(g_lamexp_temp_folder.isEmpty())
{
...
}
...
}

The Windows operating system doesn't provide any API to detect the system's TEMP folder! Neither SHGetKnownFolderPath() nor SHGetFolderPath() knows about the TEMP folder. There is a function GetTempPath(), however this function does NOT return the path to the system's TEMP folder, but the current value of the %TMP% (or if that one isn't set %TEMP%) environment variable. Now %TMP% and %TEMP% will usually be set and they will usually point to the system's TEMP path, but they also may point to an arbitrary non-writable path or they may even contain complete garbage*!

Yeah, I browsed MSDN too and didn't find any function which returns system's temporary folder. However...maybe you're thinking just a little bit too far ahead. It's the purpose of temporary environment variable to change the according folder in an easy way by the user and provide this information system-wide. I'v never seen any corrupted environment variables. Any software uses the correct path, even LameXP 3.18 ;)

Question is: How do we detect the system's TEMP folder, if the Win32 API doesn't reveal it? Solution that works in practice: Obtain the path of the 'LocalAppData' folder (usually located at: "%USERPROFILE%\AppData\Local"), which is known to the Win32 API functions, and then simply append "\Temp" to that path. The result exactly matches the system's standard TEMP folder on Win7 (and probably Vista too), which is "C:\Users\John Doe\AppData\Local\Temp".

Correct, but...

It slightly differs from WindowsXP's default TEMP folder, but I see no problem there...

That's the reason why I did that post here. Exiting LameXP v4.0 running WinXP leaves behind an empty folder in the wrong path and no other applications are using it. I know, that sounds very pedantic ;)

That is exactly how it is intended. The "primary" Temp folder needs to be accessed even before user-settings have been loaded, so it cannot be user-controlled. However that shouldn't be an issue at all, as the amount of data extracted to that folder is really small.

It's not the required disk space, but the folder left behind :p

Perhaps you could implement a function to delete it in an XP environment or create it in "%USERPROFILE%\Local Settings\Application Data\LoRd_MuldeR", if you really need this folder at this location and don't want to trust temporary variable.

--JohnJ

LoRd_MuldeR

7th March 2011, 23:38

BTW: Is this the right function which specifies temporary tool path?

Yup.

Yeah, I browsed MSDN too and didn't find any function which returns system's temporary folder.

Indeed.

However...maybe you're thinking just a little bit too far ahead. It's the purpose of temporary environment variable to change the according folder in an easy way by the user and provide this information system-wide. I'v never seen any corrupted environment variables. Any software uses the correct path, even LameXP 3.18 ;)

Well, users do kind of all strange things, such as messing with environment variables, and then forget about it. Of course when something goes wrong they'll complain to the software author.

Moreover it can even happen that other programs/installers modify environment variables. Consequently we should avoid 'uncertainties' (like depending on environment variables) as much as possible.

BTW: LameXP v3.18 used GetTempPath(), because back at that time I hadn't realized that this function is just a wrapper for getenv("TMP") :p

That's the reason why I did that post here. Exiting LameXP v4.0 running WinXP leaves behind an empty folder in the wrong path and no other applications are using it. I know, that sounds very pedantic ;)

Yes, I think this is more a pedantry than a real problem.

After all, given that all applications clean up properly, you should always find the TEMP folder empty, after exiting all running applications ;)

Perhaps you could implement a function to delete it in an XP environment or create it in "%USERPROFILE%\Local Settings\Application Data\LoRd_MuldeR", if you really need this folder at this location and don't want to trust temporary variable.

Yes, of course I could do that. But I want to avoid OS-specific code paths as much as possible. This easily creates bugs, which are hard to identify/reproduce...

mariush

7th March 2011, 23:39

In Windows, the correct way to do it is to actually use GetTempPath() ... It's designed to return the go through these one after another:

1. TMP
2. TEMP
3. User profile env. variable
4. The Windows folder

You're right, though, they're not guaranteed to be valid, even the example for this API function mentions it: http://msdn.microsoft.com/en-us/library/aa363875%28v=vs.85%29.aspx
However, it's your job to test if the folder actually exists and you can write in it, and only then if it fails, go on and use your own location.

The reason is because there are quite a few particularities and reasons why the TMP and TEMP variables are used - one I can mention from the top of my head is for example this one, where depending on how someone configures Remote Desktop, you get a different temporary folder *on purpose* : http://blogs.msdn.com/b/oldnewthing/archive/2011/01/25/10119675.aspx

If everything fails, I guess you can always fall back to Application Data and you to be careful which one to pick, because there's two of them: http://blogs.msdn.com/b/oldnewthing/archive/2005/07/01/434647.aspx . You can use SHGetFolderLocation with the right CLSID to determine the paths: http://msdn.microsoft.com/en-us/library/bb762180%28v=vs.85%29.aspx

and btw, the correct wording is actually directory, because "folders" are a virtual thing (but encapsulate regular directories): http://blogs.msdn.com/b/oldnewthing/archive/2011/02/16/10129908.aspx

LoRd_MuldeR

7th March 2011, 23:58

However, it's your job to test if the folder actually exists and you can write in it, and only then if it fails, go on and use your own location.

That sounds like feasible solution, although it adds some more complexity.

The reason is because there are quite a few particularities and reasons why the TMP and TEMP variables are used - one I can mention from the top of my head is for example this one, where depending on how someone configures Remote Desktop, you get a different temporary folder *on purpose* : http://blogs.msdn.com/b/oldnewthing/archive/2011/01/25/10119675.aspx

Well, writing my stuff to a sub-directory inside the 'application data' directory should always be admissible.

(Google's installers even install the complete application there :p)

If everything fails, I guess you can always fall back to Application Data and you to be careful which one to pick, because there's two of them: http://blogs.msdn.com/b/oldnewthing/archive/2005/07/01/434647.aspx . You can use SHGetFolderLocation with the right CLSID to determine the paths: http://msdn.microsoft.com/en-us/library/bb762180%28v=vs.85%29.aspx

Actually I use SHGetKnownFolderPath(), if available, as SHGetFolderPath() and SHGetFolderLocation() have been deprecated since Vista.

and btw, the correct wording is actually directory, because "folders" are a virtual thing (but encapsulate regular directories): http://blogs.msdn.com/b/oldnewthing/archive/2011/02/16/10129908.aspx

:eek:

John_J

8th March 2011, 01:00

and btw, the correct wording is actually directory, because "folders" are a virtual thing (but encapsulate regular directories): http://blogs.msdn.com/b/oldnewthing/archive/2011/02/16/10129908.aspx

:D Now, it goes really the pedantic way... ;)

I'll write a VB script for my personal use to start LameXP and clean up directories afterwards.

Anyways, keep on the excellent work and I hope to see your website back online, soon!

Regards,
JohnJ

LoRd_MuldeR

8th March 2011, 01:14

:D Now, it goes really the pedantic way... ;)

I'll write a VB script for my personal use to start LameXP and clean up directories afterwards.

Anyways, keep on the excellent work and I hope to see your website back online, soon!

Regards,
JohnJ

I just changed the function like mariush suggested:
LameXP will now try the directory pointed to by %TMP% first and it will only fall back to "%LOCALAPPDATA%\Temp" if the former doesn't exist or isn't writable.

See for details:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=commit;h=f2ab4c046777839d910505d2cae6330adf4b4600

Hopefully this will make everybody happy, finally :p

John_J

8th March 2011, 01:35

LameXP will now try the directory pointed to by %TMP% first and it will only fall back to "%LOCALAPPDATA%\Temp" if the former doesn't exist or isn't writable
...
Hopefully this will make everybody happy, finally :p

Yes, indeed it does! Thank you very much! :)

Romario

9th March 2011, 05:39

Thank you for newest snapshot,but, where is changelog ???

LoRd_MuldeR

9th March 2011, 11:59

New snapshot here:
http://sourceforge.net/projects/lamexp/files/Snapshots%20(BETA)/2011-03-09/

Thank you for newest snapshot,but, where is changelog ???

Changelog.html (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/Changelog.html;hb=078dc62c79f4edd1e3ba23c5deed65b5ac8fcf70) :confused:

And if you need even more details, you may look at the GIT repository's commit log:
http://gitorious.org/lamexp/lamexp/commits/master

LoRd_MuldeR

9th March 2011, 20:15

Build #360 fixes AAC encoding with CBR mode. This was broken ever since v4.00, but nobody has complained until today ;)

SeeMoreDigital

9th March 2011, 22:19

Build #360 fixes AAC encoding with CBR mode. This was broken ever since v4.00, but nobody has complained until today ;)
I'm an AAC 2-pass ABR guy myself...

codeit

10th March 2011, 10:59

Hey Mulder, thanks for the nice New Version!
I totally Love it but i got 3 Times this Error after/while encoding large Audio Files synchron (700-800MB).
Do you know what the Problem could be?
Working on an Core i5, 4GB Ram and a 64 Bit OS.

Greetings and thanks (:

C:/Users/Raphael/AppData/Local/Temp/8d64f91500e941609ee187989a324733.tmp/tool_lame.exe --nohist -q 0 --cbr -b 320 --resample 44100 -m f --lTitle "Unbekannter Titel" "C:\Users\Raphael\Desktop\VA - Trance 100 Vol.1\CD4\Unbekannter Künstler - Unbekannter Titel.wav" "C:\Users\Raphael\Desktop\VA - Trance 100 Vol.1\CD4\Unbekannter Künstler - Unbekannter Titel.mp3"

LAME 3.99 (alpha 11, Feb 14 2011 16:34:39) 32bits (http://www.mp3dev.org/)
warning: alpha versions should be used for testing only
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 20094 Hz - 20627 Hz
Encoding C:\Users\Raphael\Desktop\VA - Trance 100 Vol.1\CD4\Unbekannter K�nstler - Unbekannter Titel.wav
to C:\Users\Raphael\Desktop\VA - Trance 100 Vol.1\CD4\Unbekannter K�nstler - Unbekannter Titel.mp3
Encoding as 44.1 kHz force-ms MPEG-1 Layer III (4.4x) 320 kbps qval=0
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
Writing LAME Tag...done
ReplayGain: -6.3dB

Exited with code: 0x0000

LoRd_MuldeR

10th March 2011, 12:25

Hello, codeit.

What is the "error" you are referring to? In your log I don't see any indication of an error. Maybe wrong log posted?

(There is no error message and the LAME encoder exited normally with code 0)

codeit

10th March 2011, 15:15

Thanks for the fast Reply, that was the Error Message that appeared in the Log after the Encoding finished.

I Right-clicked on the Track with the Status: Failed and copied this Log

greetings

LoRd_MuldeR

10th March 2011, 15:19

Thanks for the fast Reply, that was the Error Message that appeared in the Log after the Encoding finished.

There is no error message in that log, that's the problem ;)

I Right-clicked on the Track with the Status: Failed and copied this Log

So I assume you copied the wrong log (maybe from the wrong item). Can you please try to re-produce the issue once more and check?

In case it really failed, but the log for the failed item says that everything went trough just fine, I'd need more detailed info on how to reproduce this...

(BTW: You didn't mention what version of LameXP you are using, but in case you are still on v4.00 Final, you may want to try the latest build)

codeit

10th March 2011, 15:36

I´ll try to reprocedure the Error later.
But i don´t think that i copied a log from a correctly encoded Track.

Actual i´m using: Version 4.00 Final, Build 326 [2011-02-21]
and i don´t updated it since the Error because it was the latest Build.
I checked it right now by encoding another Track and looked into the Log from this File, it says too: LAME 3.99 (alpha 11, Feb 14 2011 16:34:39) 32bits

LoRd_MuldeR

10th March 2011, 15:48

I´ll try to reprocedure the Error later.
But i don´t think that i copied a log from a correctly encoded Track.

Please do so. And, if you encounter an error again, please tell me what exactly didn't work (no output file at all, output file with bad content, etc.)

Actual i´m using: Version 4.00 Final, Build 326 [2011-02-21]
and i don´t updated it since the Error because it was the latest Build.

So you may want to give the latest build a try now, which you can find here:
http://sourceforge.net/projects/lamexp/files/Snapshots%20(BETA)/2011-03-09/

BTW: It seems you have selected "force joint-stereo" as your channel mode. That's not a very good idea.
It's slightly faster than the "normal" joint-stereo mode, but quality will generally be worse!

codeit

10th March 2011, 18:05

LoRd_MuldeR

10th March 2011, 19:18

Thanks for the Hint with Joint-Stereo, i´m always open for Improvements for my Music (:

Is the Updater working as intended?
If i run the Auto-Update it says Build: 326 is the latest ;-/

That must be the reason why i don´t have the latest Build.

http://i51.tinypic.com/350j991.jpg

If you check for updates in a "stable" release version, you won't find any "beta" (pre-release) updates - and that is for a good reason.

Only "beta" builds will be updated to later "beta" builds. The "stable" release will be updated to the next "stable" release as soon as a new "stable" release is available.

But of course you can always update to one of the "beta" builds manually. And you can install "beta" builds side-by-side with a "stable" build just fine...

codeit

12th March 2011, 20:12

Well, i tried to reproduce it but it, but i had no Problems encoding many large Files...Seems that everything works as usal :)

But thanks for taking time to resolve the "Problem"

davidprosser

12th March 2011, 21:43

Also, would it be possible to change the sound for when encoding is done, or at least let you close the window while it's playing that sound. I know it's not major, but, you know...just a thought!

LoRd_MuldeR

12th March 2011, 21:47

Also, would it be possible to change the sound for when encoding is done, or at least let you close the window while it's playing that sound. I know it's not major, but, you know...just a thought!

Hello, davidprosser. If you don't like the sound, you can simply disable the LameXP sound effects. Isn't that enough?

And nope, we cannot make the "complete" sound asynchronous. That's because the message box that will appear right after the sound has it's own system sound (which LameXP has no control over).

If we don't wait for the sound to finish but show the message box immediately, then the system sound replaces the previous sound, effectively suppressing the "complete" sound...

mr soft

16th March 2011, 10:45

Hey LoRd_MuldeR

Not sure if it´s just me but it seems to lag on start-up, and the first time selecting output folder.
Also when I go to add files it goes straight to my computer, it used to go to last folder used , handy if you store all your files in the same folder (like me) rather than selecting my pc/d/etc.etc each time.
MP3 channel mode simple is a bit non descriptive , Can this be changed back to stereo ?

LoRd_MuldeR

16th March 2011, 21:08

Hey LoRd_MuldeR
Not sure if it´s just me but it seems to lag on start-up, and the first time selecting output folder.

Please see:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#df406578

Also when I go to add files it goes straight to my computer, it used to go to last folder used , handy if you store all your files in the same folder (like me) rather than selecting my pc/d/etc.etc each time.

I could make the "add files" dialog remember the last folder used, yes! Yet another entry on my TODO list ;)

MP3 channel mode simple is a bit non descriptive , Can this be changed back to stereo ?

Hum?

There isn't the one "Stereo" mode. MP3 (and the LAME encoder in particular) offers different ways to encode stereo sound:

1. Dual Mono (two completely separate channels, each channel gets ½ of the bitrate)
2. Stereo (still two separate channels, but the available bitrate can be distributed between the two channels as needed)
3. Joint Stereo (encode a "mid" channel plus a "side" channel rather than distinct "left" and "right" channels, but only when useful)
4. Forced Joint Stereo (just like "Joint Stereo", but it always forces mid/side channels - even when that is worse than right/left)

Note: Normal users shouldn't enforce a specific channel mode. The "auto" mode should work just fine for almost any case!
(With "auto" mode LAME will switch between "Stereo" and "Joint Stereo", depending on the current bitrate)

LoRd_MuldeR

18th March 2011, 02:23

There now is an option to shutdown the computer when the encoding process is completed.

LeonLanford

20th March 2011, 19:50

Hi, I've used lamexp since version 3, till today there's no problem.

To make it short, I tried to convert ac3 audio with 6 channels to mp3/vorbis.
I've already successfully converted ac3 to mp3/vorbis before but not this time.

Audio
Format : AC-3
Format/Info : Audio Coding 3
Duration : 1h 35mn
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Surround: L R, LFE
Sampling rate : 48.0 KHz
Stream size : 307 MiB (100%)

The decoding process is completed successfully, but when at filtering process, it suddenly stops and I got failed status.
Here's the log

"C:/Documents and Settings/Leon Lanford/Local Settings/Application Data/Temp/66c73ef2919b4640adb5d337f197a95b.tmp/tool_valdec.exe" "C:\Documents and Settings\Leon Lanford\Desktop\[Keroro].Movie.03.[CC0F1970]_track2_jpn.ac3" -w "C:\Documents and Settings\Leon Lanford\Local Settings\Application Data\Temp\66c73ef2919b4640adb5d337f197a95b.tmp\bc21f3d3bfdf45f9bbfff80cac6d6de2.wav"

Opening audio output PCM16 3/2.1 (5.1) 48000...
[ 0.1%] Frs: 188 Err: 0 Time: 0:00.109 Level: 0 dB FPS: 1724 CPU: 21.5%
[ 0.2%] Frs: 396 Err: 0 Time: 0:00.219 Level: 0 dB FPS: 1808 CPU: 24.9%
[ 0.3%] Frs: 604 Err: 0 Time: 0:00.328 Level: 0 dB FPS: 1841 CPU: 25.1%
[ 0.4%] Frs: 809 Err: 0 Time: 0:00.437 Level: 0 dB FPS: 1851 CPU: 25.1%
[ 0.6%] Frs: 1012 Err: 0 Time: 0:00.547 Level: 0 dB FPS: 1850 CPU: 24.9%
[ 0.7%] Frs: 1214 Err: 0 Time: 0:00.656 Level: 0 dB FPS: 1850 CPU: 25.1%
[ 0.8%] Frs: 1417 Err: 0 Time: 0:00.766 Level: 0 dB FPS: 1849 CPU: 24.9%
[ 0.9%] Frs: 1617 Err: 0 Time: 0:00.875 Level: 0 dB FPS: 1848 CPU: 25.1%
[ 1.0%] Frs: 1810 Err: 0 Time: 0:00.984 Level: 0 dB FPS: 1839 CPU: 25.1%
[ 1.1%] Frs: 2009 Err: 0 Time: 0:01.094 Level: 0 dB FPS: 1836 CPU: 24.9%
[ 1.2%] Frs: 2142 Err: 0 Time: 0:01.203 Level: 0 dB FPS: 1780 CPU: 17.9%
[ 1.3%] Frs: 2289 Err: 0 Time: 0:01.312 Level: 0 dB FPS: 1744 CPU: 21.5%
[ 1.3%] Frs: 2372 Err: 0 Time: 0:01.422 Level: 0 dB FPS: 1668 CPU: 10.7%
[ 1.3%] Frs: 2419 Err: 0 Time: 0:01.531 Level: 0 dB FPS: 1580 CPU: 3.6%
[ 1.4%] Frs: 2529 Err: 0 Time: 0:01.672 Level: 0 dB FPS: 1512 CPU: 8.3%
[ 1.4%] Frs: 2604 Err: 0 Time: 0:01.781 Level: 0 dB FPS: 1462 CPU: 7.2%
[ 1.5%] Frs: 2646 Err: 0 Time: 0:01.891 Level: 0 dB FPS: 1399 CPU: 10.7%
[ 1.5%] Frs: 2673 Err: 0 Time: 0:02.000 Level: 0 dB FPS: 1336 CPU: 7.2%
[ 1.5%] Frs: 2705 Err: 0 Time: 0:02.156 Level: 0 dB FPS: 1254 CPU: 5.0%
[ 1.5%] Frs: 2776 Err: 0 Time: 0:02.266 Level: 0 dB FPS: 1225 CPU: 10.7%
[ 1.6%] Frs: 2924 Err: 0 Time: 0:02.391 Level: 0 dB FPS: 1222 CPU: 15.6%
[ 1.7%] Frs: 3006 Err: 0 Time: 0:02.500 Level: 0 dB FPS: 1202 CPU: 10.8%
[ 1.7%] Frs: 3060 Err: 0 Time: 0:02.609 Level: 0 dB FPS: 1172 CPU: 3.6%
[ 1.7%] Frs: 3124 Err: 0 Time: 0:02.750 Level: 0 dB FPS: 1136 CPU: 8.3%
[ 1.8%] Frs: 3201 Err: 0 Time: 0:02.875 Level: 0 dB FPS: 1113 CPU: 9.4%
[ 1.8%] Frs: 3318 Err: 0 Time: 0:02.984 Level: 0 dB FPS: 1111 CPU: 10.8%
[ 1.9%] Frs: 3393 Err: 0 Time: 0:03.141 Level: 0 dB FPS: 1080 CPU: 7.5%
[ 1.9%] Frs: 3510 Err: 0 Time: 0:03.297 Level: 0 dB FPS: 1064 CPU: 10.0%
[ 2.0%] Frs: 3606 Err: 0 Time: 0:03.406 Level: 0 dB FPS: 1058 CPU: 7.2%
[ 2.1%] Frs: 3700 Err: 0 Time: 0:03.516 Level: 0 dB FPS: 1052 CPU: 14.2%
[ 2.1%] Frs: 3846 Err: 0 Time: 0:03.625 Level: 0 dB FPS: 1060 CPU: 21.5%
[ 2.2%] Frs: 3959 Err: 0 Time: 0:03.734 Level: 0 dB FPS: 1060 CPU: 10.8%
[ 2.3%] Frs: 4071 Err: 0 Time: 0:03.844 Level: 0 dB FPS: 1059 CPU: 14.2%
[ 2.3%] Frs: 4137 Err: 0 Time: 0:03.953 Level: 0 dB FPS: 1046 CPU: 7.2%
[ 2.3%] Frs: 4193 Err: 0 Time: 0:04.062 Level: 0 dB FPS: 1032 CPU: 7.2%
[ 2.4%] Frs: 4257 Err: 0 Time: 0:04.172 Level: 0 dB FPS: 1020 CPU: 7.1%
[ 2.4%] Frs: 4350 Err: 0 Time: 0:04.281 Level: 0 dB FPS: 1016 CPU: 10.8%
[ 2.5%] Frs: 4429 Err: 0 Time: 0:04.391 Level: 0 dB FPS: 1008 CPU: 10.7%
[ 2.5%] Frs: 4481 Err: 0 Time: 0:04.500 Level: 0 dB FPS: 995 CPU: 7.2%
[ 2.5%] Frs: 4553 Err: 0 Time: 0:04.625 Level: 0 dB FPS: 984 CPU: 6.3%
[ 2.6%] Frs: 4630 Err: 0 Time: 0:04.734 Level: 0 dB FPS: 978 CPU: 7.2%
[ 2.6%] Frs: 4672 Err: 0 Time: 0:04.844 Level: 0 dB FPS: 964 CPU: 7.1%
[ 2.6%] Frs: 4750 Err: 0 Time: 0:04.953 Level: 0 dB FPS: 959 CPU: 7.2%
[ 2.7%] Frs: 4844 Err: 0 Time: 0:05.078 Level: 0 dB FPS: 953 CPU: 9.4%
[ 2.8%] Frs: 4968 Err: 0 Time: 0:05.187 Level: 0 dB FPS: 957 CPU: 17.9%
[ 2.8%] Frs: 5038 Err: 0 Time: 0:05.328 Level: 0 dB FPS: 945 CPU: 5.5%
[ 2.8%] Frs: 5116 Err: 0 Time: 0:05.437 Level: 0 dB FPS: 940 CPU: 7.2%
[ 2.9%] Frs: 5240 Err: 0 Time: 0:05.547 Level: 0 dB FPS: 944 CPU: 21.3%
[ 3.0%] Frs: 5361 Err: 0 Time: 0:05.656 Level: 0 dB FPS: 947 CPU: 14.3%
[ 3.0%] Frs: 5457 Err: 0 Time: 0:05.766 Level: 0 dB FPS: 946 CPU: 10.7%
[ 3.1%] Frs: 5578 Err: 0 Time: 0:05.875 Level: 0 dB FPS: 949 CPU: 14.3%
[ 3.1%] Frs: 5646 Err: 0 Time: 0:06.000 Level: 0 dB FPS: 941 CPU: 6.3%
[ 3.2%] Frs: 5750 Err: 0 Time: 0:06.109 Level: 0 dB FPS: 941 CPU: 10.8%
[ 3.3%] Frs: 5860 Err: 0 Time: 0:06.234 Level: 0 dB FPS: 940 CPU: 9.4%
[ 3.3%] Frs: 5934 Err: 0 Time: 0:06.844 Level: 0 dB FPS: 867 CPU: 1.3%
[ 3.4%] Frs: 6028 Err: 0 Time: 0:07.062 Level: 0 dB FPS: 853 CPU: 7.2% [ 3.5%] Frs: 6211 Err: 0 Time: 0:07.172 Level: 0 dB FPS: 866 CPU: 24.9%
[ 3.6%] Frs: 6411 Err: 0 Time: 0:07.281 Level: 0 dB FPS: 880 CPU: 25.1%
[ 3.7%] Frs: 6617 Err: 0 Time: 0:07.391 Level: 0 dB FPS: 895 CPU: 24.9%
[ 3.8%] Frs: 6745 Err: 0 Time: 0:07.516 Level: 0 dB FPS: 897 CPU: 12.5%
[ 3.8%] Frs: 6900 Err: 0 Time: 0:07.625 Level: 0 dB FPS: 904 CPU: 17.9%
[ 3.9%] Frs: 7043 Err: 0 Time: 0:07.734 Level: 0 dB FPS: 910 CPU: 17.9%
[ 4.0%] Frs: 7210 Err: 0 Time: 0:07.844 Level: 0 dB FPS: 919 CPU: 21.3%
[ 4.1%] Frs: 7310 Err: 0 Time: 0:07.953 Level: 0 dB FPS: 919 CPU: 10.8%
[ 4.2%] Frs: 7487 Err: 0 Time: 0:08.061 Level: 0 dB FPS: 928 CPU: 25.1%
[ 4.2%] Frs: 7605 Err: 0 Time: 0:08.172 Level: 0 dB FPS: 930 CPU: 17.8%
[ 4.3%] Frs: 7750 Err: 0 Time: 0:08.281 Level: 0 dB FPS: 935 CPU: 21.5%
[ 4.3%] Frs: 7788 Err: 0 Time: 0:08.391 Level: 0 dB FPS: 928 CPU: 3.6%
[ 4.4%] Frs: 7918 Err: 0 Time: 0:08.500 Level: 0 dB FPS: 931 CPU: 14.3%
[ 4.4%] Frs: 7958 Err: 0 Time: 0:08.609 Level: 0 dB FPS: 924 CPU: 3.6%
[ 4.5%] Frs: 8084 Err: 0 Time: 0:08.719 Level: 0 dB FPS: 927 CPU: 14.2%
[ 4.6%] Frs: 8180 Err: 0 Time: 0:08.875 Level: 0 dB FPS: 921 CPU: 7.5%
[ 4.6%] Frs: 8297 Err: 0 Time: 0:08.984 Level: 0 dB FPS: 923 CPU: 14.3%
[ 4.7%] Frs: 8388 Err: 0 Time: 0:09.094 Level: 0 dB FPS: 922 CPU: 7.1%
[ 4.7%] Frs: 8448 Err: 0 Time: 0:09.203 Level: 0 dB FPS: 917 CPU: 3.6%
[ 4.7%] Frs: 8524 Err: 0 Time: 0:09.359 Level: 0 dB FPS: 910 CPU: 7.5%
[ 4.8%] Frs: 8630 Err: 0 Time: 0:09.484 Level: 0 dB FPS: 909 CPU: 12.5%
[ 4.9%] Frs: 8734 Err: 0 Time: 0:09.594 Level: 0 dB FPS: 910 CPU: 7.1%
[ 4.9%] Frs: 8809 Err: 0 Time: 0:09.703 Level: 0 dB FPS: 907 CPU: 7.2%
[ 5.0%] Frs: 8915 Err: 0 Time: 0:09.812 Level: 0 dB FPS: 908 CPU: 14.3%
[ 5.0%] Frs: 8988 Err: 0 Time: 0:09.937 Level: 0 dB FPS: 904 CPU: 9.4%
[ 5.1%] Frs: 9081 Err: 0 Time: 0:10.047 Level: 0 dB FPS: 903 CPU: 14.2%
[ 5.1%] Frs: 9220 Err: 0 Time: 0:10.156 Level: 0 dB FPS: 907 CPU: 14.3%
[ 5.2%] Frs: 9313 Err: 0 Time: 0:10.266 Level: 0 dB FPS: 907 CPU: 10.7%
[ 5.2%] Frs: 9406 Err: 0 Time: 0:10.375 Level: 0 dB FPS: 906 CPU: 10.8%
[ 5.3%] Frs: 9548 Err: 0 Time: 0:10.484 Level: 0 dB FPS: 910 CPU: 14.3%
[ 5.4%] Frs: 9649 Err: 0 Time: 0:10.594 Level: 0 dB FPS: 910 CPU: 10.7%
[ 5.4%] Frs: 9750 Err: 0 Time: 0:10.703 Level: 0 dB FPS: 910 CPU: 17.9%
[ 5.5%] Frs: 9836 Err: 0 Time: 0:10.812 Level: 0 dB FPS: 909 CPU: 10.8%
[ 5.5%] Frs: 9910 Err: 0 Time: 0:10.922 Level: 0 dB FPS: 907 CPU: 10.7%
[ 5.6%] Frs: 9985 Err: 0 Time: 0:11.031 Level: 0 dB FPS: 905 CPU: 7.2%
[ 5.6%] Frs: 10094 Err: 0 Time: 0:11.141 Level: 0 dB FPS: 906 CPU: 14.2%
[ 5.7%] Frs: 10188 Err: 0 Time: 0:11.266 Level: 0 dB FPS: 904 CPU: 6.3%
[ 5.7%] Frs: 10260 Err: 0 Time: 0:11.375 Level: 0 dB FPS: 901 CPU: 10.8%
[ 5.8%] Frs: 10390 Err: 0 Time: 0:11.500 Level: 0 dB FPS: 903 CPU: 12.5%
[ 5.8%] Frs: 10481 Err: 0 Time: 0:11.609 Level: 0 dB FPS: 902 CPU: 10.8%
[ 5.9%] Frs: 10582 Err: 0 Time: 0:11.719 Level: 0 dB FPS: 902 CPU: 17.8%
[ 5.9%] Frs: 10681 Err: 0 Time: 0:11.828 Level: 0 dB FPS: 903 CPU: 7.2%
[ 6.0%] Frs: 10806 Err: 0 Time: 0:11.937 Level: 0 dB FPS: 905 CPU: 14.3%
[ 6.1%] Frs: 10921 Err: 0 Time: 0:12.094 Level: 0 dB FPS: 903 CPU: 10.0% [ 6.1%] Frs: 11033 Err: 0 Time: 0:12.234 Level: 0 dB FPS: 901 CPU: 11.2%
[ 6.2%] Frs: 11086 Err: 0 Time: 0:12.344 Level: 0 dB FPS: 898 CPU: 7.1%
[ 6.2%] Frs: 11188 Err: 0 Time: 0:12.484 Level: 0 dB FPS: 896 CPU: 8.4%
[ 6.3%] Frs: 11300 Err: 0 Time: 0:12.594 Level: 0 dB FPS: 897 CPU: 10.7%
[ 6.4%] Frs: 11428 Err: 0 Time: 0:12.734 Level: 0 dB FPS: 897 CPU: 11.2%
[ 6.4%] Frs: 11564 Err: 0 Time: 0:12.844 Level: 0 dB FPS: 900 CPU: 14.2%
[ 6.5%] Frs: 11601 Err: 0 Time: 0:12.953 Level: 0 dB FPS: 895 CPU: 7.2%
[ 6.5%] Frs: 11670 Err: 0 Time: 0:13.078 Level: 0 dB FPS: 892 CPU: 6.3%
[ 6.5%] Frs: 11742 Err: 0 Time: 0:13.187 Level: 0 dB FPS: 890 CPU: 7.2%
[ 6.6%] Frs: 11855 Err: 0 Time: 0:13.297 Level: 0 dB FPS: 891 CPU: 14.2%
[ 6.7%] Frs: 11956 Err: 0 Time: 0:13.406 Level: 0 dB FPS: 891 CPU: 10.8%
[ 6.7%] Frs: 12063 Err: 0 Time: 0:13.516 Level: 0 dB FPS: 892 CPU: 17.8%
[ 6.8%] Frs: 12140 Err: 0 Time: 0:13.625 Level: 0 dB FPS: 891 CPU: 7.2%
[ 6.8%] Frs: 12232 Err: 0 Time: 0:13.734 Level: 0 dB FPS: 890 CPU: 14.3%
[ 6.9%] Frs: 12361 Err: 0 Time: 0:13.844 Level: 0 dB FPS: 892 CPU: 17.8%
[ 6.9%] Frs: 12420 Err: 0 Time: 0:13.953 Level: 0 dB FPS: 890 CPU: 7.2%
[ 6.9%] Frs: 12462 Err: 0 Time: 0:14.078 Level: 0 dB FPS: 885 CPU: 3.1%
[ 7.0%] Frs: 12500 Err: 0 Time: 0:14.219 Level: 0 dB FPS: 879 CPU: 2.8%
[ 7.0%] Frs: 12571 Err: 0 Time: 0:14.328 Level: 0 dB FPS: 877 CPU: 10.8%
[ 7.1%] Frs: 12697 Err: 0 Time: 0:14.453 Level: 0 dB FPS: 878 CPU: 9.4%
[ 7.1%] Frs: 12742 Err: 0 Time: 0:14.562 Level: 0 dB FPS: 875 CPU: 7.2%
[ 7.1%] Frs: 12822 Err: 0 Time: 0:14.672 Level: 0 dB FPS: 873 CPU: 10.7%
[ 7.2%] Frs: 12948 Err: 0 Time: 0:14.812 Level: 0 dB FPS: 874 CPU: 11.2%
[ 7.3%] Frs: 13078 Err: 0 Time: 0:14.922 Level: 0 dB FPS: 876 CPU: 14.2%
[ 7.3%] Frs: 13164 Err: 0 Time: 0:15.031 Level: 0 dB FPS: 875 CPU: 7.2%
[ 7.4%] Frs: 13222 Err: 0 Time: 0:15.156 Level: 0 dB FPS: 872 CPU: 6.3%
[ 7.4%] Frs: 13337 Err: 0 Time: 0:15.266 Level: 0 dB FPS: 873 CPU: 17.8%
[ 7.5%] Frs: 13441 Err: 0 Time: 0:15.391 Level: 0 dB FPS: 873 CPU: 12.5%
[ 7.6%] Frs: 13564 Err: 0 Time: 0:15.500 Level: 0 dB FPS: 875 CPU: 14.3%
[ 7.6%] Frs: 13689 Err: 0 Time: 0:15.609 Level: 0 dB FPS: 876 CPU: 17.9%
[ 7.7%] Frs: 13798 Err: 0 Time: 0:15.719 Level: 0 dB FPS: 877 CPU: 10.7%
[ 7.7%] Frs: 13873 Err: 0 Time: 0:15.828 Level: 0 dB FPS: 876 CPU: 10.8%
[ 7.8%] Frs: 13996 Err: 0 Time: 0:15.937 Level: 0 dB FPS: 878 CPU: 14.3%
[ 7.8%] Frs: 14060 Err: 0 Time: 0:16.047 Level: 0 dB FPS: 876 CPU: 10.7%
[ 7.9%] Frs: 14142 Err: 0 Time: 0:16.155 Level: 0 dB FPS: 875 CPU: 7.2%
[ 8.0%] Frs: 14282 Err: 0 Time: 0:16.265 Level: 0 dB FPS: 878 CPU: 17.8%
[ 8.0%] Frs: 14356 Err: 0 Time: 0:16.375 Level: 0 dB FPS: 876 CPU: 7.2%
[ 8.0%] Frs: 14438 Err: 0 Time: 0:16.500 Level: 0 dB FPS: 875 CPU: 12.5%
[ 8.1%] Frs: 14562 Err: 0 Time: 0:16.609 Level: 0 dB FPS: 876 CPU: 14.3%
[ 8.2%] Frs: 14661 Err: 0 Time: 0:16.719 Level: 0 dB FPS: 876 CPU: 10.7%
[ 8.2%] Frs: 14702 Err: 0 Time: 0:16.828 Level: 0 dB FPS: 873 CPU: 3.6%
[ 8.2%] Frs: 14780 Err: 0 Time: 0:16.937 Level: 0 dB FPS: 872 CPU: 14.3%
[ 8.3%] Frs: 14838 Err: 0 Time: 0:17.047 Level: 0 dB FPS: 870 CPU: 3.6%
[ 8.3%] Frs: 14953 Err: 0 Time: 0:17.172 Level: 0 dB FPS: 870 CPU: 15.6%
[ 8.4%] Frs: 15074 Err: 0 Time: 0:17.281 Level: 0 dB FPS: 872 CPU: 17.9%
[ 8.4%] Frs: 15150 Err: 0 Time: 0:17.391 Level: 0 dB FPS: 871 CPU: 7.1%
[ 8.5%] Frs: 15222 Err: 0 Time: 0:17.516 Level: 0 dB FPS: 869 CPU: 6.3%
[ 8.5%] Frs: 15308 Err: 0 Time: 0:17.625 Level: 0 dB FPS: 868 CPU: 10.8%
[ 8.6%] Frs: 15393 Err: 0 Time: 0:17.734 Level: 0 dB FPS: 867 CPU: 3.6%
[ 8.6%] Frs: 15513 Err: 0 Time: 0:17.844 Level: 0 dB FPS: 869 CPU: 17.8%
[ 8.7%] Frs: 15606 Err: 0 Time: 0:17.953 Level: 0 dB FPS: 869 CPU: 14.3%
[ 8.8%] Frs: 15732 Err: 0 Time: 0:18.062 Level: 0 dB FPS: 870 CPU: 14.3%
[ 8.8%] Frs: 15798 Err: 0 Time: 0:18.172 Level: 0 dB FPS: 869 CPU: 7.1%
[ 8.9%] Frs: 15900 Err: 0 Time: 0:18.344 Level: 0 dB FPS: 866 CPU: 6.8%
[ 8.9%] Frs: 15972 Err: 0 Time: 0:18.453 Level: 0 dB FPS: 865 CPU: 7.2%
[ 8.9%] Frs: 16068 Err: 0 Time: 0:18.562 Level: 0 dB FPS: 865 CPU: 14.3%
[ 9.0%] Frs: 16165 Err: 0 Time: 0:18.672 Level: 0 dB FPS: 865 CPU: 14.2%
[ 9.0%] Frs: 16247 Err: 0 Time: 0:18.781 Level: 0 dB FPS: 865 CPU: 10.8%
[ 9.1%] Frs: 16361 Err: 0 Time: 0:18.891 Level: 0 dB FPS: 866 CPU: 10.7%
[ 9.1%] Frs: 16423 Err: 0 Time: 0:19.000 Level: 0 dB FPS: 864 CPU: 10.8%
[ 9.2%] Frs: 16492 Err: 0 Time: 0:19.109 Level: 0 dB FPS: 863 CPU: 10.8%
[ 9.2%] Frs: 16553 Err: 0 Time: 0:19.234 Level: 0 dB FPS: 860 CPU: 3.1%
[ 9.3%] Frs: 16639 Err: 0 Time: 0:19.344 Level: 0 dB FPS: 860 CPU: 10.7%
[ 9.3%] Frs: 16724 Err: 0 Time: 0:19.469 Level: 0 dB FPS: 859 CPU: 6.3%
[ 9.4%] Frs: 16838 Err: 0 Time: 0:19.578 Level: 0 dB FPS: 860 CPU: 14.3%
[ 9.4%] Frs: 16889 Err: 0 Time: 0:19.687 Level: 0 dB FPS: 857 CPU: 10.8%
[ 9.4%] Frs: 16958 Err: 0 Time: 0:19.812 Level: 0 dB FPS: 855 CPU: 9.4%
[ 9.5%] Frs: 17033 Err: 0 Time: 0:19.922 Level: 0 dB FPS: 854 CPU: 14.2%
[ 9.5%] Frs: 17111 Err: 0 Time: 0:20.031 Level: 0 dB FPS: 854 CPU: 10.8%
[ 9.6%] Frs: 17236 Err: 0 Time: 0:20.141 Level: 0 dB FPS: 855 CPU: 17.8%
[ 9.7%] Frs: 17332 Err: 0 Time: 0:20.266 Level: 0 dB FPS: 855 CPU: 6.3%
[ 9.7%] Frs: 17398 Err: 0 Time: 0:20.375 Level: 0 dB FPS: 853 CPU: 7.2%
[ 9.7%] Frs: 17478 Err: 0 Time: 0:20.516 Level: 0 dB FPS: 851 CPU: 2.8%
[ 9.8%] Frs: 17550 Err: 0 Time: 0:20.625 Level: 0 dB FPS: 850 CPU: 10.8%
[ 9.8%] Frs: 17582 Err: 0 Time: 0:20.750 Level: 0 dB FPS: 847 CPU: 0.0%
[ 9.8%] Frs: 17654 Err: 0 Time: 0:20.875 Level: 0 dB FPS: 845 CPU: 6.3%
[ 9.9%] Frs: 17726 Err: 0 Time: 0:20.984 Level: 0 dB FPS: 844 CPU: 14.3%
[ 9.9%] Frs: 17857 Err: 0 Time: 0:21.094 Level: 0 dB FPS: 846 CPU: 14.2%
---------------------------------------
Frames/errors: 179426/0
System time: 143844ms
Process time: 97343ms
Approx. 1.70% realtime CPU usage

Exited with code: 0x0000

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

"C:/Documents and Settings/Leon Lanford/Local Settings/Application Data/Temp/66c73ef2919b4640adb5d337f197a95b.tmp/tool_sox.exe" -V3 --guard --temp . "C:\Documents and Settings\Leon Lanford\Local Settings\Application Data\Temp\66c73ef2919b4640adb5d337f197a95b.tmp\bc21f3d3bfdf45f9bbfff80cac6d6de2.wav" -c2 "C:\Documents and Settings\Leon Lanford\Local Settings\Application Data\Temp\66c73ef2919b4640adb5d337f197a95b.tmp\c647b8be01354dab95e60e54ac5ee241.wav"

Exited with code: 0xF291

From the log I think that the conversion to wav succeeded but not wav to mp3. I tested this by converting to wav first and it works but I cannot convert the wav to mp3 or vorbis.

I also tried to convert it to flac first but still failed at the filtering process(successfully got the flac audio), from the log I saw that flac got converted to wav first not directly to mp3. I think the problem is at the wav?

But at last I successfully converted the audio, I converted the flac to vorbis using foobar2000 conversion tool.
That's why I thought there's nothing wrong with the audio, I just want to post this bug here.

Thanks for the great app :D

LoRd_MuldeR

20th March 2011, 20:16

LeonLanford,

it seems like SoX failed when downmixing the intermediate Wave file to two channels. The downmix is required for MP3 encoding, as the MP3 format is Stereo only.

Multi-channel AC3 to MP3 conversion seems to work okay for me:
http://pastie.org/private/3dlynbbsuux4hj9v02i2a

Can you provide a short sample file to re-produce the issue? Also, what version are you using?

mariush

20th March 2011, 21:29

I can reproduce it here, was just curious about it and tried it with a 250 MB dts file :

"C:/Documents and Settings/Administrator/Local Settings/Application Data/Temp/5c288acc28c647468fcca6736e957179.tmp/tool_valdec.exe" "S:\a.dts" -w
"C:\Documents and Settings\Administrator\Local Settings\Application Data\Temp\5c288acc28c647468fcca6736e957179.tmp\202cc1cf91e94536a076a298b3412181.wav"

Opening audio output PCM16 3/2.1 (5.1) 48000...
[ 0.0%] Frs: 209 Err: 0 Time: 0:00.110 Level: 0 dB FPS: 1900 CPU: 7.1%
[ 0.1%] Frs: 535 Err: 0 Time: 0:00.219 Level: 0 dB FPS: 2442 CPU: 25.1%
[ 0.1%] Frs: 966 Err: 0 Time: 0:00.328 Level: 0 dB FPS: 2945 CPU: 25.1%
[ 0.2%] Frs: 1391 Err: 0 Time: 0:00.438 Level: 0 dB FPS: 3175 CPU: 24.9%
[ 0.3%] Frs: 1694 Err: 0 Time: 0:00.547 Level: 0 dB FPS: 3096 CPU: 21.5%
[ 0.3%] Frs: 2096 Err: 0 Time: 0:00.656 Level: 0 dB FPS: 3195 CPU: 25.1%
[ 0.4%] Frs: 2419 Err: 0 Time: 0:00.766 Level: 0 dB FPS: 3157 CPU: 10.7%
[ 0.4%] Frs: 2655 Err: 0 Time: 0:00.875 Level: 0 dB FPS: 3034 CPU: 17.9%
[ 0.5%] Frs: 3000 Err: 0 Time: 0:00.985 Level: 0 dB FPS: 3045 CPU: 21.3%
[ 0.5%] Frs: 3303 Err: 0 Time: 0:01.094 Level: 0 dB FPS: 3019 CPU: 14.3%
[ 0.5%] Frs: 3560 Err: 0 Time: 0:01.203 Level: 0 dB FPS: 2959 CPU: 17.9%
[ 0.6%] Frs: 3882 Err: 0 Time: 0:01.313 Level: 0 dB FPS: 2956 CPU: 21.3%
[ 0.6%] Frs: 4246 Err: 0 Time: 0:01.422 Level: 0 dB FPS: 2985 CPU: 25.1%
[ 0.7%] Frs: 4568 Err: 0 Time: 0:01.531 Level: 0 dB FPS: 2983 CPU: 17.9%
[ 0.7%] Frs: 4943 Err: 0 Time: 0:01.641 Level: 0 dB FPS: 3012 CPU: 21.3%
[ 0.8%] Frs: 5327 Err: 0 Time: 0:01.750 Level: 0 dB FPS: 3044 CPU: 17.9%
[ 0.9%] Frs: 5709 Err: 0 Time: 0:01.860 Level: 0 dB FPS: 3069 CPU: 21.3%
[ 0.9%] Frs: 6054 Err: 0 Time: 0:01.969 Level: 0 dB FPS: 3074 CPU: 21.5%
[ 1.0%] Frs: 6495 Err: 0 Time: 0:02.078 Level: 0 dB FPS: 3125 CPU: 25.1%
[ 1.0%] Frs: 6922 Err: 0 Time: 0:02.188 Level: 0 dB FPS: 3163 CPU: 24.9%
[ 1.1%] Frs: 7350 Err: 0 Time: 0:02.297 Level: 0 dB FPS: 3199 CPU: 25.1%
[ 1.2%] Frs: 7768 Err: 0 Time: 0:02.406 Level: 0 dB FPS: 3228 CPU: 25.1%
[ 1.2%] Frs: 8191 Err: 0 Time: 0:02.516 Level: 0 dB FPS: 3255 CPU: 24.9%
[ 1.3%] Frs: 8609 Err: 0 Time: 0:02.625 Level: 0 dB FPS: 3279 CPU: 25.1%
[ 1.4%] Frs: 9022 Err: 0 Time: 0:02.735 Level: 0 dB FPS: 3298 CPU: 17.8%
[ 1.4%] Frs: 9433 Err: 0 Time: 0:02.844 Level: 0 dB FPS: 3316 CPU: 21.5%
[ 1.5%] Frs: 9856 Err: 0 Time: 0:02.953 Level: 0 dB FPS: 3337 CPU: 21.5%
[ 1.5%] Frs: 10225 Err: 0 Time: 0:03.063 Level: 0 dB FPS: 3338 CPU: 24.9%
[ 1.6%] Frs: 10614 Err: 0 Time: 0:03.172 Level: 0 dB FPS: 3346 CPU: 25.1%
[ 1.7%] Frs: 11014 Err: 0 Time: 0:03.281 Level: 0 dB FPS: 3356 CPU: 17.9%
[ 1.7%] Frs: 11446 Err: 0 Time: 0:03.391 Level: 0 dB FPS: 3375 CPU: 24.9%
[ 1.8%] Frs: 11799 Err: 0 Time: 0:03.500 Level: 0 dB FPS: 3371 CPU: 21.5%
[ 1.8%] Frs: 12206 Err: 0 Time: 0:03.610 Level: 0 dB FPS: 3381 CPU: 24.9%
[ 1.9%] Frs: 12630 Err: 0 Time: 0:03.719 Level: 0 dB FPS: 3396 CPU: 25.1%
[ 2.0%] Frs: 12986 Err: 0 Time: 0:03.828 Level: 0 dB FPS: 3392 CPU: 21.5%
[ 2.0%] Frs: 13345 Err: 0 Time: 0:03.938 Level: 0 dB FPS: 3388 CPU: 17.8%
[ 2.1%] Frs: 13728 Err: 0 Time: 0:04.046 Level: 0 dB FPS: 3392 CPU: 25.1%
[ 2.1%] Frs: 14146 Err: 0 Time: 0:04.156 Level: 0 dB FPS: 3403 CPU: 25.1%
[ 2.2%] Frs: 14477 Err: 0 Time: 0:04.266 Level: 0 dB FPS: 3393 CPU: 14.2%
[ 2.2%] Frs: 14890 Err: 0 Time: 0:04.375 Level: 0 dB FPS: 3403 CPU: 21.5%
[ 2.3%] Frs: 15304 Err: 0 Time: 0:04.485 Level: 0 dB FPS: 3412 CPU: 24.9%
[ 2.4%] Frs: 15692 Err: 0 Time: 0:04.594 Level: 0 dB FPS: 3415 CPU: 21.5%
[ 2.4%] Frs: 16126 Err: 0 Time: 0:04.703 Level: 0 dB FPS: 3428 CPU: 25.1%
[ 2.5%] Frs: 16559 Err: 0 Time: 0:04.813 Level: 0 dB FPS: 3440 CPU: 24.9%
[ 2.6%] Frs: 16990 Err: 0 Time: 0:04.922 Level: 0 dB FPS: 3451 CPU: 25.1%
[ 2.6%] Frs: 17362 Err: 0 Time: 0:05.031 Level: 0 dB FPS: 3451 CPU: 21.5%
[ 2.7%] Frs: 17798 Err: 0 Time: 0:05.141 Level: 0 dB FPS: 3461 CPU: 24.9%
[ 2.7%] Frs: 18206 Err: 0 Time: 0:05.250 Level: 0 dB FPS: 3467 CPU: 21.5%
[ 2.8%] Frs: 18628 Err: 0 Time: 0:05.360 Level: 0 dB FPS: 3475 CPU: 24.9%
[ 2.9%] Frs: 19047 Err: 0 Time: 0:05.469 Level: 0 dB FPS: 3482 CPU: 21.5%
[ 2.9%] Frs: 19464 Err: 0 Time: 0:05.578 Level: 0 dB FPS: 3489 CPU: 25.1%
[ 3.0%] Frs: 19842 Err: 0 Time: 0:05.688 Level: 0 dB FPS: 3488 CPU: 24.9%
[ 3.0%] Frs: 20199 Err: 0 Time: 0:05.797 Level: 0 dB FPS: 3484 CPU: 21.5%
[ 3.1%] Frs: 20585 Err: 0 Time: 0:05.906 Level: 0 dB FPS: 3485 CPU: 25.1%
[ 3.2%] Frs: 21010 Err: 0 Time: 0:06.016 Level: 0 dB FPS: 3492 CPU: 24.9%
[ 3.2%] Frs: 21434 Err: 0 Time: 0:06.125 Level: 0 dB FPS: 3499 CPU: 25.1%
[ 3.3%] Frs: 21873 Err: 0 Time: 0:06.235 Level: 0 dB FPS: 3508 CPU: 24.9%
[ 3.4%] Frs: 22275 Err: 0 Time: 0:06.344 Level: 0 dB FPS: 3511 CPU: 21.5%
[ 3.4%] Frs: 22696 Err: 0 Time: 0:06.453 Level: 0 dB FPS: 3517 CPU: 25.1%
[ 3.5%] Frs: 23125 Err: 0 Time: 0:06.563 Level: 0 dB FPS: 3523 CPU: 24.9%
[ 3.5%] Frs: 23475 Err: 0 Time: 0:06.672 Level: 0 dB FPS: 3518 CPU: 25.1%
[ 3.6%] Frs: 23909 Err: 0 Time: 0:06.781 Level: 0 dB FPS: 3525 CPU: 25.1%
[ 3.7%] Frs: 24315 Err: 0 Time: 0:06.891 Level: 0 dB FPS: 3528 CPU: 24.9%
[ 3.7%] Frs: 24703 Err: 0 Time: 0:07.000 Level: 0 dB FPS: 3529 CPU: 25.1%
[ 3.8%] Frs: 25079 Err: 0 Time: 0:07.110 Level: 0 dB FPS: 3527 CPU: 17.8%
[ 3.8%] Frs: 25450 Err: 0 Time: 0:07.219 Level: 0 dB FPS: 3525 CPU: 14.3%
[ 3.9%] Frs: 25876 Err: 0 Time: 0:07.328 Level: 0 dB FPS: 3531 CPU: 25.1%
[ 4.0%] Frs: 26297 Err: 0 Time: 0:07.438 Level: 0 dB FPS: 3535 CPU: 24.9%
[ 4.0%] Frs: 26715 Err: 0 Time: 0:07.547 Level: 0 dB FPS: 3539 CPU: 25.1%
[ 4.1%] Frs: 27134 Err: 0 Time: 0:07.656 Level: 0 dB FPS: 3544 CPU: 25.1%
[ 4.1%] Frs: 27494 Err: 0 Time: 0:07.766 Level: 0 dB FPS: 3540 CPU: 21.3%
[ 4.2%] Frs: 27846 Err: 0 Time: 0:07.875 Level: 0 dB FPS: 3536 CPU: 21.5%
[ 4.3%] Frs: 28251 Err: 0 Time: 0:07.985 Level: 0 dB FPS: 3538 CPU: 21.3%
[ 4.3%] Frs: 28679 Err: 0 Time: 0:08.093 Level: 0 dB FPS: 3543 CPU: 25.1%
[ 4.4%] Frs: 29096 Err: 0 Time: 0:08.203 Level: 0 dB FPS: 3546 CPU: 25.1%
[ 4.5%] Frs: 29526 Err: 0 Time: 0:08.313 Level: 0 dB FPS: 3551 CPU: 24.9%
[ 4.5%] Frs: 29952 Err: 0 Time: 0:08.422 Level: 0 dB FPS: 3556 CPU: 25.1%
[ 4.6%] Frs: 30373 Err: 0 Time: 0:08.531 Level: 0 dB FPS: 3560 CPU: 25.1%
[ 4.6%] Frs: 30809 Err: 0 Time: 0:08.641 Level: 0 dB FPS: 3565 CPU: 24.9%
[ 4.7%] Frs: 31197 Err: 0 Time: 0:08.750 Level: 0 dB FPS: 3565 CPU: 21.5%
[ 4.8%] Frs: 31630 Err: 0 Time: 0:08.860 Level: 0 dB FPS: 3569 CPU: 24.9%
[ 4.8%] Frs: 32070 Err: 0 Time: 0:08.969 Level: 0 dB FPS: 3575 CPU: 25.1%
[ 4.9%] Frs: 32430 Err: 0 Time: 0:09.078 Level: 0 dB FPS: 3572 CPU: 17.9%
[ 5.0%] Frs: 32863 Err: 0 Time: 0:09.188 Level: 0 dB FPS: 3576 CPU: 24.9%
[ 5.0%] Frs: 33268 Err: 0 Time: 0:09.297 Level: 0 dB FPS: 3578 CPU: 21.5%
[ 5.1%] Frs: 33699 Err: 0 Time: 0:09.406 Level: 0 dB FPS: 3582 CPU: 25.1%
[ 5.2%] Frs: 34127 Err: 0 Time: 0:09.516 Level: 0 dB FPS: 3586 CPU: 24.9%
[ 5.2%] Frs: 34546 Err: 0 Time: 0:09.625 Level: 0 dB FPS: 3589 CPU: 25.1%
[ 5.3%] Frs: 34982 Err: 0 Time: 0:09.735 Level: 0 dB FPS: 3593 CPU: 24.9%
[ 5.3%] Frs: 35415 Err: 0 Time: 0:09.844 Level: 0 dB FPS: 3597 CPU: 25.1%
[ 5.4%] Frs: 35787 Err: 0 Time: 0:09.953 Level: 0 dB FPS: 3595 CPU: 17.9%
[ 5.5%] Frs: 36216 Err: 0 Time: 0:10.063 Level: 0 dB FPS: 3598 CPU: 24.9%
[ 5.5%] Frs: 36569 Err: 0 Time: 0:10.172 Level: 0 dB FPS: 3595 CPU: 25.1%
[ 5.6%] Frs: 36919 Err: 0 Time: 0:10.281 Level: 0 dB FPS: 3590 CPU: 21.5%
[ 5.6%] Frs: 37346 Err: 0 Time: 0:10.391 Level: 0 dB FPS: 3594 CPU: 21.3%
[ 5.7%] Frs: 37765 Err: 0 Time: 0:10.500 Level: 0 dB FPS: 3596 CPU: 21.5%
[ 5.8%] Frs: 38161 Err: 0 Time: 0:10.610 Level: 0 dB FPS: 3596 CPU: 21.3%
[ 5.8%] Frs: 38495 Err: 0 Time: 0:10.719 Level: 0 dB FPS: 3591 CPU: 21.5%
[ 5.9%] Frs: 38923 Err: 0 Time: 0:10.828 Level: 0 dB FPS: 3594 CPU: 25.1%
[ 5.9%] Frs: 39292 Err: 0 Time: 0:10.938 Level: 0 dB FPS: 3592 CPU: 17.8%
[ 6.0%] Frs: 39726 Err: 0 Time: 0:11.047 Level: 0 dB FPS: 3596 CPU: 25.1%
[ 6.1%] Frs: 40113 Err: 0 Time: 0:11.156 Level: 0 dB FPS: 3595 CPU: 21.5%
[ 6.1%] Frs: 40545 Err: 0 Time: 0:11.266 Level: 0 dB FPS: 3598 CPU: 24.9%
[ 6.2%] Frs: 40982 Err: 0 Time: 0:11.375 Level: 0 dB FPS: 3602 CPU: 25.1%
[ 6.2%] Frs: 41404 Err: 0 Time: 0:11.485 Level: 0 dB FPS: 3605 CPU: 24.9%
[ 6.3%] Frs: 41834 Err: 0 Time: 0:11.594 Level: 0 dB FPS: 3608 CPU: 25.1%
[ 6.4%] Frs: 42260 Err: 0 Time: 0:11.703 Level: 0 dB FPS: 3611 CPU: 25.1%
[ 6.4%] Frs: 42647 Err: 0 Time: 0:11.813 Level: 0 dB FPS: 3610 CPU: 21.3%
[ 6.5%] Frs: 43078 Err: 0 Time: 0:11.922 Level: 0 dB FPS: 3613 CPU: 21.5%
[ 6.6%] Frs: 43492 Err: 0 Time: 0:12.031 Level: 0 dB FPS: 3614 CPU: 25.1%
[ 6.6%] Frs: 43873 Err: 0 Time: 0:12.141 Level: 0 dB FPS: 3613 CPU: 21.3%
[ 6.7%] Frs: 44294 Err: 0 Time: 0:12.250 Level: 0 dB FPS: 3615 CPU: 25.1%
[ 6.8%] Frs: 44726 Err: 0 Time: 0:12.360 Level: 0 dB FPS: 3618 CPU: 24.9%
[ 6.8%] Frs: 45135 Err: 0 Time: 0:12.469 Level: 0 dB FPS: 3619 CPU: 25.1%
[ 6.9%] Frs: 45548 Err: 0 Time: 0:12.578 Level: 0 dB FPS: 3621 CPU: 25.1%
[ 6.9%] Frs: 45923 Err: 0 Time: 0:12.688 Level: 0 dB FPS: 3619 CPU: 17.8%
[ 7.0%] Frs: 46356 Err: 0 Time: 0:12.797 Level: 0 dB FPS: 3622 CPU: 25.1%
[ 7.1%] Frs: 46766 Err: 0 Time: 0:12.906 Level: 0 dB FPS: 3623 CPU: 21.5%
[ 7.1%] Frs: 47112 Err: 0 Time: 0:13.016 Level: 0 dB FPS: 3619 CPU: 21.3%
[ 7.2%] Frs: 47533 Err: 0 Time: 0:13.125 Level: 0 dB FPS: 3621 CPU: 25.1%
[ 7.2%] Frs: 47946 Err: 0 Time: 0:13.235 Level: 0 dB FPS: 3622 CPU: 24.9%
[ 7.3%] Frs: 48294 Err: 0 Time: 0:13.344 Level: 0 dB FPS: 3619 CPU: 25.1%
[ 7.4%] Frs: 48699 Err: 0 Time: 0:13.453 Level: 0 dB FPS: 3619 CPU: 25.1%
[ 7.4%] Frs: 49126 Err: 0 Time: 0:13.563 Level: 0 dB FPS: 3622 CPU: 21.3%
[ 7.5%] Frs: 49529 Err: 0 Time: 0:13.672 Level: 0 dB FPS: 3622 CPU: 25.1%
[ 7.5%] Frs: 49923 Err: 0 Time: 0:13.781 Level: 0 dB FPS: 3622 CPU: 21.5%
[ 7.6%] Frs: 50350 Err: 0 Time: 0:13.891 Level: 0 dB FPS: 3624 CPU: 24.9%
[ 7.7%] Frs: 50790 Err: 0 Time: 0:14.000 Level: 0 dB FPS: 3627 CPU: 25.1%
[ 7.7%] Frs: 51214 Err: 0 Time: 0:14.110 Level: 0 dB FPS: 3629 CPU: 24.9%
[ 7.8%] Frs: 51645 Err: 0 Time: 0:14.219 Level: 0 dB FPS: 3632 CPU: 25.1%
[ 7.9%] Frs: 52064 Err: 0 Time: 0:14.328 Level: 0 dB FPS: 3633 CPU: 21.5%
[ 7.9%] Frs: 52488 Err: 0 Time: 0:14.438 Level: 0 dB FPS: 3635 CPU: 24.9%
[ 8.0%] Frs: 52923 Err: 0 Time: 0:14.547 Level: 0 dB FPS: 3638 CPU: 25.1%
[ 8.1%] Frs: 53335 Err: 0 Time: 0:14.688 Level: 0 dB FPS: 3631 CPU: 13.9%
[ 8.1%] Frs: 53730 Err: 0 Time: 0:14.797 Level: 0 dB FPS: 3631 CPU: 25.1%
[ 8.2%] Frs: 54163 Err: 0 Time: 0:14.906 Level: 0 dB FPS: 3633 CPU: 25.1%
[ 8.2%] Frs: 54603 Err: 0 Time: 0:15.016 Level: 0 dB FPS: 3636 CPU: 24.9%
[ 8.3%] Frs: 55009 Err: 0 Time: 0:15.125 Level: 0 dB FPS: 3636 CPU: 21.5%
[ 8.4%] Frs: 55458 Err: 0 Time: 0:15.235 Level: 0 dB FPS: 3640 CPU: 24.9%
[ 8.4%] Frs: 55901 Err: 0 Time: 0:15.344 Level: 0 dB FPS: 3643 CPU: 25.1%
[ 8.5%] Frs: 56332 Err: 0 Time: 0:15.453 Level: 0 dB FPS: 3645 CPU: 25.1%
[ 8.6%] Frs: 56774 Err: 0 Time: 0:15.563 Level: 0 dB FPS: 3648 CPU: 24.9%
[ 8.6%] Frs: 57166 Err: 0 Time: 0:15.672 Level: 0 dB FPS: 3647 CPU: 21.5%
[ 8.7%] Frs: 57571 Err: 0 Time: 0:15.781 Level: 0 dB FPS: 3648 CPU: 25.1%
[ 8.8%] Frs: 58017 Err: 0 Time: 0:15.891 Level: 0 dB FPS: 3650 CPU: 24.9%
[ 8.8%] Frs: 58470 Err: 0 Time: 0:16.000 Level: 0 dB FPS: 3654 CPU: 25.1%
[ 8.9%] Frs: 58912 Err: 0 Time: 0:16.110 Level: 0 dB FPS: 3656 CPU: 24.9%
[ 9.0%] Frs: 59359 Err: 0 Time: 0:16.219 Level: 0 dB FPS: 3659 CPU: 25.1%
[ 9.0%] Frs: 59759 Err: 0 Time: 0:16.328 Level: 0 dB FPS: 3659 CPU: 25.1%
[ 9.1%] Frs: 60200 Err: 0 Time: 0:16.438 Level: 0 dB FPS: 3662 CPU: 21.3%
[ 9.2%] Frs: 60619 Err: 0 Time: 0:16.547 Level: 0 dB FPS: 3663 CPU: 25.1%
[ 9.2%] Frs: 61058 Err: 0 Time: 0:16.656 Level: 0 dB FPS: 3665 CPU: 21.5%
[ 9.3%] Frs: 61445 Err: 0 Time: 0:16.766 Level: 0 dB FPS: 3664 CPU: 17.8%
[ 9.3%] Frs: 61887 Err: 0 Time: 0:16.875 Level: 0 dB FPS: 3667 CPU: 25.1%
[ 9.4%] Frs: 62327 Err: 0 Time: 0:16.985 Level: 0 dB FPS: 3669 CPU: 24.9%
[ 9.5%] Frs: 62762 Err: 0 Time: 0:17.094 Level: 0 dB FPS: 3671 CPU: 25.1%
[ 9.5%] Frs: 63120 Err: 0 Time: 0:17.203 Level: 0 dB FPS: 3669 CPU: 25.1%
[ 9.6%] Frs: 63518 Err: 0 Time: 0:17.313 Level: 0 dB FPS: 3668 CPU: 24.9%
[ 9.6%] Frs: 63910 Err: 0 Time: 0:17.422 Level: 0 dB FPS: 3668 CPU: 21.5%
[ 9.7%] Frs: 64327 Err: 0 Time: 0:17.531 Level: 0 dB FPS: 3669 CPU: 25.1%
[ 9.8%] Frs: 64758 Err: 0 Time: 0:17.641 Level: 0 dB FPS: 3670 CPU: 24.9%
[ 9.8%] Frs: 65150 Err: 0 Time: 0:17.750 Level: 0 dB FPS: 3670 CPU: 25.1%
[ 9.9%] Frs: 65584 Err: 0 Time: 0:17.860 Level: 0 dB FPS: 3672 CPU: 24.9%
---------------------------------------
Frames/errors: 662346/0
System time: 176000ms
Process time: 170937ms
Approx. 2.42% realtime CPU usage

Exited with code: 0x0000

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

"C:/Documents and Settings/Administrator/Local Settings/Application Data/Temp/5c288acc28c647468fcca6736e957179.tmp/tool_sox.exe" -V3 --guard --temp .
"C:\Documents and Settings\Administrator\Local Settings\Application Data\Temp\5c288acc28c647468fcca6736e957179.tmp\202cc1cf91e94536a076a298b3412181.wav" -c2
"C:\Documents and Settings\Administrator\Local Settings\Application Data\Temp\5c288acc28c647468fcca6736e957179.tmp\8e7d3206d277495fa253f24183fd7eb9.wav"

Exited with code: 0xF291

I'm not sure you'd supposed to mix / and \ in a command line but I don't think that's the problem - after all you get an exit code

This exit code 62097 (F291) seems pretty popular with mplayer/smplayer , google it..

Later edit:

While decoding to wav, I opened the wav in vlc so that a file handle remains open and the file will remain after lamexp tries to delete them.
So I ran the command manually :

C:\[....]\Temp\5c2
88acc28c647468fcca6736e957179.tmp>tool_sox.exe -V3 --guard --temp . a8bb0312ad2d
4b7fba9a54da9f31fc11.wav -c2 temp.wav
tool_sox.exe: SoX v14.3.1
tool_sox.exe INFO formats: detected file format type `wav'
tool_sox.exe INFO wav: EXTENSIBLE

Input File : 'a8bb0312ad2d4b7fba9a54da9f31fc11.wav'
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 01:57:44.89 = 339114496 samples ~ 529866 CDDA sectors
File Size : 4.07G
Bit Rate : 4.61M
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no

Output File : 'temp.wav'
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Duration : 01:57:44.89 = 339114496 samples ~ 529866 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'

tool_sox.exe INFO sox: effects chain: input 48000Hz 6 channels
tool_sox.exe INFO sox: effects chain: gain 48000Hz 6 channels
tool_sox.exe INFO sox: effects chain: channels 48000Hz 2 channels
tool_sox.exe INFO sox: effects chain: dither 48000Hz 2 channels
tool_sox.exe INFO sox: effects chain: output 48000Hz 2 channels

The output seems correct, wav file plays fine in videolan and is detected correctly as wav stereo.

LoRd_MuldeR

20th March 2011, 21:41

Does this only happen with very big AC3/DTS files? If so, the problem might be that the decoded Wave file is bigger than 4GB :eek:

mariush

20th March 2011, 21:50

No, in my case the temp wav generated before sox was 3.78 GB (4,069,374,056 bytes) . lamexp crashed it when triggering sox, but when i did it manually it worked fine. I didn't use the folders in the parameters though, so the whole command line was much smaller (could it be the case?)

Anyway, it's risky to use by default the C: drive.. i usually have a few GB only - now I had 7 GB... if someone rips a dts from a movie, you're making a 4 GB wav, then a 1.25 GB with sox ...

People will start to buy 40-80GB SSDs just for the OS and the situation probably won't improve in the future

ps. The length of the path to the temp files in my case is 170. You're getting close to the 256 limit on Windows - some programs have issues with that.

LoRd_MuldeR

20th March 2011, 22:13

No, in my case the temp wav generated before sox was 3.78 GB (4,069,374,056 bytes) . lamexp crashed it when triggering sox, but when i did it manually it worked fine. I didn't use the folders in the parameters though, so the whole command line was much smaller (could it be the case?)

Strange. It shouldn't make any difference whether LameXP calls SoX or you do it manually. The length of the command-line shouldn't be an issue.

Anyway, it's risky to use by default the C: drive.. i usually have a few GB only - now I had 7 GB... if someone rips a dts from a movie, you're making a 4 GB wav, then a 1.25 GB with sox ...

That's why a warning will pop up when the disk space runs low. Also the intermediate files are stored in the secondary (user-defined) temp folder...

ps. The length of the path to the temp files in my case is 170. You're getting close to the 256 limit on Windows - some programs have issues with that.

As far as I know, there is no way around the MAX_PATH limit on Windows. The limit is 260 tough ^^

mariush

20th March 2011, 22:25

LoRd_MuldeR

21st March 2011, 01:05

For people that just start the application and just upgrade when the message pops up, well, they don't know such feature has been added without reading about it somewhere. I don't know how many people check each menu with every upgrade. Maybe a small window below the "new update available" or when the new version starts for the first time describing the significant changes would be useful?

Well, there is the Changelog, at which anybody can look. I even added a shortcut to the Changelog to the Help menu recently.

Regarding file names. The actual limit is 256, because the MAX_PATH is 260 and you're using 3 for "X:\" and the fourth for the terminating NULL character.

I would consider the drive letter as a part of a fully-qualified path, but that's hairsplitting again ;)

Anyway, this is an API limit, and it's no longer the case for the Unicode versions of most functions - see this article: http://msdn.microsoft.com/en-us/library/Aa365247 - you can use up to about 32767 *bytes* (utf8 characters can take 1 to 3-5 bytes, normally maximum 3, more utf8 accepts and is valid according to standard, but for simplicity you're not supposed to use them)

The problem is you can't reliably know those command line tools are compiled and know how to read files with such long file names, without checking each one and building your own version, I'd say it's at least unreliable.

Even though the Win32 API support paths up to 32767 characters now, when the proper functions are used and when a special prefix is added to the path, it seems impossible to create paths longer than 260 characters in total on a physical disk. I don't know if that is a limitation of the filesystem, a limitation of the Windows Explorer or if they simply prevent longer file names for backward-compatibility reasons.

Anyway, on Windows 7 the length of the path to the default %TEMP% folder is 28 characters + length of the user account name (35 in total here). That's enough room for LameXP to create its temporary files.

mariush

21st March 2011, 02:22

It's quite possible to create and work with such files, it's just that you need to use the unicode functions instead of the default ANSI ones. Oh, and I think you have to be sure each segment of the path is below 260 ansi characters.

Here's a code I wrote right now in a few minutes... it's visual basic 6 but uses the windows api:

Private Type SECURITY_ATTRIBUTES
nLength As Long
lpSecurityDescriptor As Long
bInheritHandle As Long
End Type

Private Const FILE_SHARE_READ = &H1
Private Const FILE_SHARE_WRITE = &H2

Private Declare Function CreateDirectory Lib "kernel32" Alias "CreateDirectoryW" (ByVal lpPathName As String, lpSecurityAttributes As SECURITY_ATTRIBUTES) As Long
Private Declare Function CreateFile Lib "kernel32" Alias "CreateFileW" (ByVal lpFileName As String, ByVal dwDesiredAccess As Long, ByVal dwShareMode As Long, ByVal lpSecurityAttributes As Long, ByVal dwCreationDisposition As Long, ByVal dwFlagsAndAttributes As Long, ByVal hTemplateFile As Long) As Long
Private Declare Function CloseHandle Lib "kernel32" (ByVal hObject As Long) As Long

Private Sub Form_Load()
Dim ret As Long
Dim s As String
Dim sec As SECURITY_ATTRIBUTES

Const folname As String = "This is a folder with a very long name because I like very long names and nobody can stop me from making them, they are so cool and magical"
Const filname As String = "This is a file with a very long name because I like very long names and nobody can stop me from making them, they are so cool and magical"

ret = CreateDirectory(s, sec)
MsgBox "Created folder " & folname & ", got reply " & CStr(ret) & " (0 means failure)"
s = StrConv("\\?\C:\" & folname & "\" & filname, vbUnicode)
ret = CreateFile(s, GENERIC_WRITE, FILE_SHARE_READ Or FILE_SHARE_WRITE, ByVal 0&, CREATE_ALWAYS, 0, 0&)
MsgBox "Created file ::" & folname & "::, in the previously created folder, got handle " & CStr(ret)
ret = CloseHandle(ret)
end sub

The result is this:

http://savedonthe.net/image/871/Clipboard01.png

Total length 281 characters.

Funny though, stuff like echo "1" >"This..." doesn't work, as it won't find the file... same with copy con "this..."

C:\This is a folder with a very long name because I like very long names and nob
ody can stop me from making them, they are so cool and magical>copy CON "This is
a file with a very long name because I like very long names and nobody can stop
me from making them, they are so cool and magical"
The file name is too long.
0 file(s) copied.

ps. the vb6 "to unicode" functions converts it to utf-16 (two bytes per character) so that may be where you went wrong before if you tried it"

LeonLanford

21st March 2011, 13:43

@mulder
as mariush already said, it's wav to mp3/vorbis bug (haven't tested with other).
my wav is only 3gb, less than mariush's.
I have 20gb free space so I don't think space is the problem and I'm using the latest lamexp #326.

I think there's also no problem with long filenames, I have longer filenames before and it worked. Like I said before, I tried to convert to wav first, after that convert it to mp3/vorbis but still failed.

"C:/Documents and Settings/Leon Lanford/Local Settings/Application Data/Temp/0903bfae0f0d4faa8bdb392e36f54688.tmp/tool_oggenc2_sse2.exe" -b 56 -o "C:\Documents and Settings\Leon Lanford\Desktop\[Keroro].Movie.03.[CC0F1970]_track2_jpn.ogg" "C:\Documents and Settings\Leon Lanford\Desktop\[Keroro].Movie.03.[CC0F1970]_track2_jpn.wav"

Skipping chunk of type "JUNK", length 28
Opening with wav module: WAV file reader
Mode initialisation failed: invalid parameters for bitrate

Exited with code: 0x0001

I think something is wrong with the wav reader? I can convert the wav with foobar2000 conversion tool.
Sorry I cannot provide sample because my upload speed is really slow, maybe you can ask mariush.

LoRd_MuldeR

21st March 2011, 13:58

Hmm, I would understand if SoX failed to process Wave files with a size of 4+ GB, as normal Wave files can't exceed a size of 4 GB (a limitation to the underlying RIFF format).

So AC3Filter/Valibdec will output "RF64" Wave files, if the final size actually exceeds 4 GB. Wouldn't be a surprise of SoX failed to process such RF64 files, but with ~3GB files it should work.

I will try to re-produce the issue with a bigger Wave file. But if that turns out to be a limitation in SoX, there's not much I can do about it...

LoRd_MuldeR

21st March 2011, 15:17

Okay, I just converted an 6ch AC3 file, which I had extracted from one of my DVD's, to the MP3 format with LameXP.

Everything went through just fine:
http://pastie.org/private/r3u9ngl7p875mm5p1j6pyg
:confused:

The size of the source AC3 file is 316 MB, the intermediate Wave file was like ~3 GB in size, the downmixed version was still about 1 GB in size.

As you can see, the decoding (Valibdec), the downmixing (SoX) and the encoding (LAME) all completed successfully...

BTW: I just fixed a minor bug in LameXP's code for parsing the Valibdec output. This bug caused the log to be flooded with messages like this:
[ 0.5%] Frs: 3560 Err: 0 Time: 0:01.203 Level: 0 dB FPS: 2959 CPU: 17.9%

mariush

21st March 2011, 23:53

LoRd_MuldeR

22nd March 2011, 00:39

What's with the

Duration : 01:34:07.97 = 271102464 samples ~ 423598 CDDA sectors
File Size : 42949672.00G
Bit Rate : 42949672.442949672.00G

in the pastie log? 32bit signed/unsigned issue? I didn't get that with the almost 4GB wav made from the dts file.

Not sure. I will try with a DTS file later or tomorrow.

Meanwhile:
First attempt for cover artwork support.

LoRd_MuldeR

4th April 2011, 22:12

LameXP v4.01 Final :)
https://github.com/lordmulder/LameXP/downloads

Changes between v4.00 and v4.01:
* Added an option to manually specify the number of parallel instances
* Added an option to select a user-defined TEMP directory
* Added an option to shutdown the computer as soon as all files are completed
* Added an option to add directories recursively
* Added support for embedding cover artwork (currently works with LAME, FLAC and Nero AAC only)
* Updated Qt runtime libraries to v4.7.2
* Updated LAME encoder to v3.99.0.16 (2011-04-04), compiled with ICL 12.0.2
* Updated Vorbis encoder to v2.87 using aoTuV Beta-6.02 (2011-02-28), compiled with ICL 11.1 and MSVC 9.0
* Updated TTA decoder multiplatform library to v2.1 (2011-03-11), compiled with MSVC 9.0
* Updated SoX to v14.3.2 (2010-02-27), compiled with ICL 12.0.2
* Updated MediaInfo to v0.7.43 (2011-03-20), compiled with ICL 12.0.2 and MSVC 9.0
* Updated language files (big thank-you to all contributors !!!)
* Fixed a problem with the LAME encoder that could cause glitches (VBR mode), reported by Wolfgang Waldeck
* Fixed a problem with the LAME encoder that could cause very slow encoding speed
* Fixed a bug that caused AAC encoding to fail in CBR mode (the "-2pass" parameter was set wrongly)
* A warning message will be emitted, if diskspace drops below a critical limit while processing

LoRd_MuldeR

8th April 2011, 22:21

New experimental snapshot available:

This is the first build compiled with Visual Studio 2010, so please report any issues you may encounter.
Due to a limitation of Visual Studio 2010, the minimum supported operating system is Windows XP with Service Pack 2 from now on.
Furthermore we have a new translation: Korean!

LoRd_MuldeR

11th April 2011, 14:42

I overhauled the initialization routine, so the startup should be slightly faster now, as fewer files need to be extracted.

(BTW: Is anybody else experiencing that SourceForge suddenly takes extremely long, like 5 hours or so, to make new downloads available?)

lethedoom

11th April 2011, 15:34

"(BTW: Is anybody else experiencing that SourceForge suddenly takes extremely long, like 5 hours or so, to make new downloads available?)"

For what it is worth I have been offered and downloaded updates using LameXP 'Check For Updates' before they appeared on the beta folder list @ http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/

LoRd_MuldeR

11th April 2011, 15:42

For what it is worth I have been offered and downloaded updates using LameXP 'Check For Updates' before they appeared on the beta folder list @ http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/

That's not a surprise. The auto-update server is completely unrelated to the SourceForge file release system.

And I usually push updates to the auto-update server first, before uploading them to other mirrors. However no updates have been pushed to auto-update since the v4.01 final release.

So all builds prior to #418 should still update #418 (aka "v4.01 final") and later snapshot builds should not update at all, at the time being...

digitaltoast

13th April 2011, 10:54

I'm liking the new Lame build 4.01 especially now the "hanging when selecting output folder is fixed" but talking of ogg...

BTW, can anyone explain me why newer Ogg encoders produce significially larger files than the older ones?

I've noticed that when using quality based vbr, the output size of 0, -1 and -2 quality is always identical.

When using abr bitrate, at very low bitrates (32k) speech sounds like it has a tiny but noticeable "echo" to it. Has anyone else heard this? Is there a setting to get round this?

Apart from that - great!

LoRd_MuldeR

13th April 2011, 20:12

I'm liking the new Lame build 4.01 especially now the "hanging when selecting output folder is fixed"

I did not fix anything with that regard. If there was any improvement, then it is because I updated the Qt framework to v4.7.2 ;)

but talking of ogg...

I've noticed that when using quality based vbr, the output size of 0, -1 and -2 quality is always identical.

When using abr bitrate, at very low bitrates (32k) speech sounds like it has a tiny but noticeable "echo" to it. Has anyone else heard this? Is there a setting to get round this?

Apart from that - great!

I don't do a lot of ultra-low bitrate encodes, but maybe what your hear is a side-effect of the the latest aoTuV Vorbis tweaks? :confused:

(BTW: Maybe you want to try a Speech-Codec, like Speex, for ultra-low bitrate speech encodes)

LoRd_MuldeR

16th April 2011, 21:34

New experimental snapshot available:
LAME v3.99 has finally gone Beta. Please see the LAME Changelog (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.127) for details :)

LoRd_MuldeR

19th April 2011, 22:06

New experimental snapshot available:
http://sourceforge.net/projects/lamexp/files/Snapshots%20(BETA)/2011-04-19/

Updated to Qt SDK v1.1 (Qt v4.7.3).

codeit

20th April 2011, 19:25

LoRd_MuldeR

20th April 2011, 22:04

I just Updated to the newest Version and everytime i encode with CBR/320kbit/s the Final File is encoded @ 160kbit/s

I tried it a few times but everytime i encode it the 160kbit/s File is the Result

Is this a Bug?

Hard to say, as you didn't even tell us what encoder you were using (LAME, Vorbis, Nero AAC) or at least provide your log :confused:

Please give me exact instructions how to reproduce the problem you have encountered and I will be able to analyze and, if it is a bug, fix it.

(Oh, and it might also be helpful if you tell us how you "measure" the resulting bitrate and conclude that it is wrong)

mr soft

22nd April 2011, 16:30

LoRd_MuldeR

22nd April 2011, 19:47

:thanks: again for all your work.

A few hiccups I’ve encountered.
It ignores language selected on install, does it install by region ? I ask because I have an English OS with a Spanish keyboard and Spanish region selected, I select English, it then installs in Spanish.:confused:

Well, the language you select in the installer is for the install program. It does not (yet) influence the (initial) language of the main program.

The language of the main program should default to your system's language (if we have that language, otherwise English) and can be changed in the language menu.

Making the installer set the initial language would make sense. But unfortunately we have much more main program translations than installer translations...

It doesn’t seem to be importing my old settings, ie. I uninstalled the older version selecting, keep settings. installed newer version and it outputs files at the default installation settings. I then reverted back to the 3.6 final build and all my compression/settings were automatically recognized. I´m also still experiencing a lot of lag when selecting output, ( am I the only one ?) this is also not present with 3.6 final

The configuration is stored separately for each version, as with every version new settings might be introduced, obsolete settings might be removed and/or existing settings might change their meaning. Version 3.xx and version 4.xx use completely different configuration files anyway, as the application has been rewritten from the scratch.

Oh yeh , almost forgot , you asked about antivirus, I´m using Avira.

In my experience Avira Antivir has one of the fastest real-time scanners. Also Avira support responds quickly to report of false positives.

Ps what happened to the floating mines when you click about, and the moving cd. :)

These were cookies (http://spurgo.de/blog/wp-content/cookie.jpg), not mines. The 'feature' was removed to avoid confusion. But I can add something similar to v4.xx :p

http://www.illninofans.de/soad/images/smilies/kruemel.gif (http://www.techybytes.com/images/delete-cookies1.jpg)

LoRd_MuldeR

25th April 2011, 21:21

New experimental snapshot available:

This build includes a workaround for a regression in latest MediaInfo, as described in this (http://forum.doom9.org/showpost.php?p=1495395&postcount=937) post.
Note that LameXP v4.01 (build #418) is not effected by this problem, because it still used a slightly older MediaInfo, which didn't exhibit the problem.
My workaround doesn't entirely fix the problem. There still can be problems if "\n" or "\r" appear inside meta tags...

Octo-puss

26th April 2011, 21:11

Oh I only just discovered this thread after thinking wth happened with LameXP over all those months of not hearing about it :P
Good to see you still working on it (althought I can't imagine what else do you possibly need to improve about this already good program).

edit: Where are you getting the alpha LAME version from? The latest update on their web was who knows how many months ago.

LoRd_MuldeR

26th April 2011, 21:44

Oh I only just discovered this thread after thinking wth happened with LameXP over all those months of not hearing about it :P

And auto-update didn't fetch the update for you? Or did you disable auto-update?

edit: Where are you getting the alpha LAME version from? The latest update on their web was who knows how many months ago.

The LAME project does not release any binaries. Only sources. I check out the sources from the CVS repository on their official SourceForge.net web-site and make my own build.

Another great site for getting pre-compiled binaries of various audio encoders/decoders is Rarewares.org (http://www.rarewares.org/). Oh, and LAME v3.99 is in BETA stage now ;)

Octo-puss

27th April 2011, 10:44

Well I haven't made any mp3s for like year and a half, so that explains :P

I was checking changelog on http://lame.sourceforge.net/ and the changelog doesn't change much. I lived under the impression it was kind of up to date as it lists betas changes too.

LoRd_MuldeR

27th April 2011, 20:15

I was checking changelog on http://lame.sourceforge.net/ and the changelog doesn't change much. I lived under the impression it was kind of up to date as it lists betas changes too.

Well, since v3.99 went "beta", the Changelog has been updated:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=HEAD

For more detailed information you will have to look directly at the CVS repository listing:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/libmp3lame/?sortby=date

(Note that CVS, in contrast to SVN, only manages histories of individual files rather than a complete project history.
Something like 'cvs2cl.pl' may be used to generate a human-readable changelog from CVS hsitories)

LoRd_MuldeR

2nd May 2011, 17:40

New experimental snapshot available:
Updated MediaInfo to SVN-r3975, which fixes the line-break bug (regression in MediaInfo v0.7.44), and consequently removed the workaround.

LoRd_MuldeR

5th May 2011, 20:57

New experimental snapshot available:

This version introduces ATSC A/52 (aka "AC-3") encoding support, using Aften v0.0.8+ (Git Head).
Also the Ogg Vorbis encoder has been updated to aoTuV beta 6.03.

Motenai Yoda

6th May 2011, 15:45

I noticed that on transcoding from flac to mp3, with the stable build, a little delay (about 2200 samples) seems to be added to the beginning of each file...
and why the normalization option isn't settable on 0.0dB?

LoRd_MuldeR

6th May 2011, 16:19

I noticed that on transcoding from flac to mp3, with the stable build, a little delay (about 2200 samples) seems to be added to the beginning of each file...

It's due to the ID3 tag (or the Xing header) prepended by LAME, I guess ;)

ID3v2 tags (in contrast to ID3v1) are stored at the beginning of the MP3 file and they are camouflaged as (silent) mp3 frames to retain compatibility with the original mp3 standard.

Decoders aware of ID3v2/Xing will probably discard these frames (maybe by option), while other decoders will decode them happily as silent samples...

(One mp3 frame covers exactly 1152 samples, so from your description it seems you got two extra frames)

and why the normalization option isn't settable on 0.0dB?

One shouldn't normalize up to the maximum possible sample value in order to avoid distortions, especially with respect to Audio-CD players.

See also:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#434f2578

(To make a long story short: Even if all samples values are at most 0dBFS in the digital domain, the reconstructed analogue signal may still exceed 0dBFS and thus cause distortion)

SeeMoreDigital

7th May 2011, 14:52

This version introduces ATSC A/52 (aka "AC-3") encoding support, using Aften v0.0.8+ (Git Head). Fan- freckin'-tastic...

I just generated a few tests, converting 6Ch AAC to 6Ch AC3. All went well and very fast :)

I'm lovin' it

~bT~

8th May 2011, 12:43

I don't know if anyone else uses this program for you-tube videos. I drop the mp4 file in and output mp3's without needing to extract the audio 1st.

Great piece of software which works like it should. Thanks!!!

EDIT: I'm not sure if it will work but can you see if you can add .flv support please?

LoRd_MuldeR

8th May 2011, 13:33

EDIT: I'm not sure if it will work but can you see if you can add .flv support please?

Well, FLV is a container format. It may contain various audio formats, including (but not limited to) the MP3 format.

The MP3 decoder that is used in LameXP, which is mpg123, doesn't support FLV as input. So we would need to extract the MP3 stream from the FLV container first.

However I'm not aware of a suitable tool for that purpose. There is FLV Extract by Moitah, but unfortunately it's a .NET application....

(And currently I don't feel like porting it to plain C/C++ ^^)

LoRd_MuldeR

10th May 2011, 17:21

New experimental snapshot available:
Language updates + auto-updater improvements + doc updates.

LoRd_MuldeR

15th May 2011, 02:00

New experimental snapshot available:

http://imageshack.us/m/38/4926/importcuesheetomarrodri.png

The Cue Sheet import wizard was added :cool:

LoRd_MuldeR

16th May 2011, 20:06

New experimental snapshot available:

The Cue Sheet import wizard should now also be able to import tracks from files that are not Wave/PCM.

Build #532 improved the precision of the Cue Sheet splitter. The cut points were calculated slightly wrong before.

So please run auto-update, if you intend to test the Cue Sheet import feature!

Dogway

18th May 2011, 20:09

edit: ignore I misclicked something

your software rocks. maybe the double confirmation is too much, and the dos windows a bit annoying but well its still demo.

LoRd_MuldeR

18th May 2011, 20:30

maybe the double confirmation is too much, and the dos windows a bit annoying but well its still demo.

What "double confirmation" you are referring to? Most info/warning dialogs can be disabled under "Extras" -> "Configuration".

About what you call a "DOS window", please read this section of the FAQ document:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#900a2a6c

Dogway

18th May 2011, 21:14

Thanks! Hope a stable release soon. Maybe is not your intention, but would be cool to acept .avs sources in a future I have like 5 different programs only for audio lol

LoRd_MuldeR

18th May 2011, 21:29

Thanks! Hope a stable release soon. Maybe is not your intention, but would be cool to acept .avs sources in a future I have like 5 different programs only for audio lol

Well, Avisyth is mainly a video editor and frame-server, so it's a bit out of scope for my little audio converter.

But if you can name a simple CLI tool that can dump the audio stream from an Avisynth file to an uncompressed Wave file, I will look into it :)

[EDIT]

Okay, found "avs2wav.exe". So you can expect AVS input soon...

LoRd_MuldeR

19th May 2011, 23:26

New experimental snapshot available:

This version adds support for Avisynth input (of course audio only!). I'm using a stripped-down/cleaned-up version of avs2wav (http://forum.doom9.org/showthread.php?p=926711#post926711) for this purpose. I also updated avs2wav to support Unicode file names (src (http://code.google.com/p/mulder/source/browse/trunk/Utils/avs2wav#avs2wav%2Favs2wav)), but unfortunately there is a strange issue with AVIFileOpenW(). When passing a Unicode file name, it will succeed to open the AVS file (even when file doesn't exist!), but will later fail to find any streams. I don't know if this is a bug in Windows or some mistake on my side. I also checked out the native Avisynth API, but apparently it doesn't support Unicode strings at all. Looks like a lost cause...

LoRd_MuldeR

21st May 2011, 15:05

New experimental snapshot available:

This is a bugfix release: Before the Nero AAC options was not grayed out correctly, if the Nero AAC encoder is missing and Nero AAC notifications are disabled.
As a result the user could select Nero AAC as encoder even if it wasn't available. In this case LameXP would crash after starting the encode...

Dogway

25th May 2011, 19:19

LoRd_MuldeR

25th May 2011, 19:53

Its strange I tried loading an .avs and when encoding the process stayed idle at decoding stage. My script is nice because it could play on MPC... but even a nicac3source("source.ac3") didn't work.

Can you post your complete Avisynth script and provide a link to the source audio file that was used in the script?

In my tests I did use NiceAC3Source() too and it worked fine for me :confused:

Do I need huge spare memory on my HDD

You will, of course, need enough HDD space to dump the complete audio track to an uncompressed Wave file.

However the maximum size you will ever need is 4 GB, simply because RIFF/Wave files cannot grow larger than 4 GB and my tool will fail in that case :p

(I know that there is the RF64 format, which can be used to circumvent the 4 GB limit, but I current have no plans to support it)

Dogway

25th May 2011, 20:12

Its strange because I tested with megui too and it also failed. This never happened to me so I think the cause could be I recently upgraded to avisynth 2.58, by some reason I always sticked to 2.57, maybe this is why.
Now Im back to 2.57 and uninstalled megui, I will install it again and recheck. Source is a 2h ac3 so I think in this case lameXP wont work.

LoRd_MuldeR

25th May 2011, 20:21

Its strange because I tested with megui too and it also failed. This never happened to me so I think the cause could be I recently upgraded to avisynth 2.58, by some reason I always sticked to 2.57, maybe this is why.

This sounds like something is wrong with your Avisynth. I highly suggest to make a clean un-install of Avisynth and all the plug-in's!

Then re-install the latest stable Avisynth (v2.58) and add only the plug-in you need for the test...

Now Im back to 2.57 and uninstalled megui, I will install it again and recheck. Source is a 2h ac3 so I think in this case lameXP wont work.

If that's a 5.1 channel source, then it can be problematic. Two hours of uncompressed 6 channel audio may easily exceed the 4 GB limit.

Still 'avs2wav' wouldn't simply stall in that situation. It would dump to the end of the stream and then fail to close/finalize the Wave file properly...

(It seems many applications will actually ignore the size field in the RIFF/Wave header and play all the way to the end of the physical file)

SeeMoreDigital

25th May 2011, 20:36

LoRd_MuldeR, have you seen this topic started by Kurtnoise: http://forum.doom9.org/showthread.php?t=161383

Cheers

Dogway

25th May 2011, 20:41

yep, there's something bad going on. Fresh Megui Install didn't work with .avs, instead it worked with the .ac3 but I normally prefer to tell the encoder how to downmix the channels than being it done blindly.
That depicts an error with avisynth probably.
BeHappy also triggered an error: Error: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

LoRd_MuldeR

25th May 2011, 21:10

LoRd_MuldeR, have you seen this topic started by Kurtnoise: http://forum.doom9.org/showthread.php?t=161383

Interesting. But the 'libav' patch alone isn't much of a use for me. If somebody makes a lightweight CLI en/decoder from that, I'd be happy to include it...

nitinpushpan

27th May 2011, 06:47

LoRd_MuldeR

27th May 2011, 10:41

I'm using v4.01 Final-1, Build 418 [2011-04-04] of LameXP. Recently while dragging & dropping a folder (containing flac files), I got a files rejected message (which is normal because it contained a album art jpg). I then noticed that the explorer window that I dragged the folder from would remain frozen until I clicked OK on the 'Files Rejected' message box.

It's not really a bug. It's by design ;)

The files are added from the Drag&Drop event handler routine. Obviously the Explorer doesn't respond until the event handler has returned.

Didn't know that this is an issue, but it was easy to implement a workaround. The files are now added in an asynchronous way, so the event handler can return ASAP.

Please try build #552, which will be available from build #540 (http://sourceforge.net/projects/lamexp/files/Snapshots%20(BETA)/2011-05-21/) (or any other post-#418 build) via Auto-Update shortly. It is available now.

LoRd_MuldeR

29th May 2011, 17:17

LameXP v4.02 Beta-5:
http://sourceforge.net/projects/lamexp/files/Snapshots%20(BETA)/2011-05-29/

Probably the last v4.02 beta release. Please report any problems as soon as possible ;)

digitaltoast

29th May 2011, 18:46

LoRd_MuldeR

29th May 2011, 19:03

Now this is strange. A while back, I had this problem with the "output directory" taking a long time to come up. With this new static binary, where the command prompt is in the background window, this is happening again.
You click "output directory", it hangs, empty, for exactly 15 seconds, then directories appear and there is a spinner for 5 seconds, then you can use that tab.

Fast PC, plenty of RAM, nothing else running. Is there anything I can do to help diagnose why this is?

This is because the QFileSystemModel takes a moment to initialize. It probably depends on the number of files/subdirs in the initial directory.

As QFileSystemModel is part of the Qt Framework (not my own code!) there is not much I can do about it, unfortunately :rolleyes:

Seem the problem is known though:
http://www.qtcentre.org/threads/38938-QTreeView-QFileSystemModel-VERY-slow-on-some-Windows-machines

Raen

30th May 2011, 20:12

Hey there! Been a loyal user of LameXP for some years now and glad that you continue to regularly update it :cool:

I could make the "add files" dialog remember the last folder used, yes! Yet another entry on my TODO list ;)

Yes, that would be some useful thing to have :)

The Cue Sheet import wizard was added :cool:

Glad you added full CUE support, because I experienced some bizarre things with CUE files.
Supposedly they are supported by LameXP, but dragging one CUE file to LameXP gives an error.

http://img802.imageshack.us/img802/3893/unled2nh.th.jpg (http://imageshack.us/photo/my-images/802/unled2nh.jpg/)http://img827.imageshack.us/img827/9337/lamexpcue.th.jpg (http://imageshack.us/photo/my-images/827/lamexpcue.jpg/)

Or LameXP (v4.01) doesn't support CUE files of FLAC files?
If not, are they supported with the new Cue Sheet import wizard?

I am using CUETools for this splitting job (mostly with FLAC files), and converting with LameXP afterwards.

I also have some slowness when opening the "Output Directory" tab for the 1st time after running LameXP, about 3-5 seconds until it opens.
Then, every time I click "+" to explore a folder, to see its sub-folders, another 3-5 seconds of hanging.
But if I go to a folder that i explored before in the same LameXP session, no hanging happens, it shows the sub-folders instantly.

At least I'm happy that the "Output Directory" tab remembers the last folder used, even in the previous LameXP session.

Now, I've some bug reports and requests (some of them, features that should return from the v3.18 version):

M3U playlists in "Artist - Album.m3u" format.

Something that v3.18 was cool at, and LameXP v4.01 is creating M3U playlists in "Album.m3u" format.

":" should be converted to " - " in the M3U's filename.

LameXP v4.01 is replacing ":" with space or simply eliminating it.
(Also featured in v3.18)

M3U playlists made by LameXP after converting don't recognize/open files with special characters like accents ("é", "ã", "ö", ...), "ß", "ø", etc in their filename.

Maybe creating M3U8 (unicode) playlists instead of M3U solves the problem?

Button to copy file's album information to "Metadata" tab, like v3.18 had.

"Genre" in the "Metadata" tab should be editable/writable if pretended, just like "artist" or "album" field.

Some tracks have more than 1 genre or genres that are not listed.

Option to hide/disable the DropBox (maybe under "Tools"->"Configuration" similar to the other options there).

Sometimes the DropBox gets in the way when you have multiple windows open for example.

Option to edit destination filenames.

In "Source Files" tab you have the "Title" column, then the "Full Path" column.
Maybe putting a new "Destination File" column between these already existing two, would do the trick.

It could be directly editable/writable or should have some formula/parameters, like if the track title is "X", then the destination file name would be "01. X.mp3", where "01" is the track number.

The destination filename creation parameters should be editable, like for example EAC (Exact Audio Copy) has, or something like LameXP has in the "Advanced Options" tab in "Custom Encoder Parameters"

http://img718.imageshack.us/img718/2712/unled4l.th.jpg (http://imageshack.us/photo/my-images/718/unled4l.jpg/)

I suggest this because I often edit beforehand one by one the filenames of the files I want to convert, so LameXP converts and playlists them with the filenames that I pretend, because LameXP names the converted files according to the original filenames by default.

If this feature was implemented, users like me that like to have files by a certain filename standard, would save a lot of work.

Track details window should have FULL bitrate, encoder, etc info just like v3.18 had.

v3.18 VS v4.01
http://img638.imageshack.us/img638/9899/unled3sx.th.jpg (http://imageshack.us/photo/my-images/638/unled3sx.jpg/) VS http://img847.imageshack.us/img847/8526/unled5y.th.jpg (http://imageshack.us/photo/my-images/847/unled5y.jpg/)

If minimized, LameXP goes back to the "Source Files" tab when you open/restore its window.
It should remember which tab you were using before minimizing.

Also, when I have the time, I'm looking forward to do a Portuguese (PT-PT) translation for LameXP :cool: :)

Keep up the good work!

LoRd_MuldeR

30th May 2011, 21:21

Glad you added full CUE support, because I experienced some bizarre things with CUE files.
Supposedly they are supported by LameXP, but dragging one CUE file to LameXP gives an error.

http://img802.imageshack.us/img802/3893/unled2nh.th.jpg (http://imageshack.us/photo/my-images/802/unled2nh.jpg/)http://img827.imageshack.us/img827/9337/lamexpcue.th.jpg (http://imageshack.us/photo/my-images/827/lamexpcue.jpg/)

Or LameXP (v4.01) doesn't support CUE files of FLAC files?
If not, are they supported with the new Cue Sheet import wizard?

I am using CUETools for this splitting job (mostly with FLAC files), and converting with LameXP afterwards.

LameXP v4.01 does not support CUE files. LameXP v3.xx only had very limited/bad support for CUE files - splitting was not implemented at all!

Starting with LameXP v4.02 there is a CUE import wizard, which finally supports splitting the input files according to the information from CUE sheet.

Also LameXP does support any type of input file from CUE sheets, including Wave, MP3 and FLAC files.

However I don't know what the correct syntax for FLAC files in a CUE sheet is. Actaully I think using FLAC files as a source in a CUE sheet is non-standard!

Nonetheless currently LameXP will accept FLAC files from "FILE <Path> WAVE" as well as "FILE <Path> MP3".

I also have some slowness when opening the "Output Directory" tab for the 1st time after running LameXP, about 3-5 seconds until it opens.
Then, every time I click "+" to explore a folder, to see its sub-folders, another 3-5 seconds of hanging.
But if I go to a folder that i explored before in the same LameXP session, no hanging happens, it shows the sub-folders instantly.

Obviously the first time a folder is accessed there is a delay, because the folder has to be scanned.

If you access the folder again, the info is already in the cache...

M3U playlists in "Artist - Album.m3u" format.

Something that v3.18 was cool at, and LameXP v4.01 is creating M3U playlists in "Album.m3u" format.

Actually the format should be "<Artist> - <Album>.m3u", but only if both, the album artist and the album name, are known.

Are you sure you entered this info on the "Meta Data" tab?

M3U playlists made by LameXP after converting don't recognize/open files with special characters like accents ("é", "ã", "ö", ...), "ß", "ø", etc in their filename.

Maybe creating M3U8 (unicode) playlists instead of M3U solves the problem?

LameXP v4.xx offers full Unicode support. Playlists are exported in the UTF-8 format. Probably the extension should be .m3u8 though...

Button to copy file's album information to "Metadata" tab, like v3.18 had.

Added to my "TODO" list

"Genre" in the "Metadata" tab should be editable/writable if pretended, just like "artist" or "album" field.

The "genre" field on the "Meta Data" tab is editable, isn't it? :confused:

Some tracks have more than 1 genre or genres that are not listed.

The available genres are pre-defined. I simply used the ones that are supported by LAME. I think these are the ones defined by ID3.

Option to hide/disable the DropBox (maybe under "Tools"->"Configuration" similar to the other options there).

You can close the Dropbox by right-click, as is indicated by the tool tip.

Sometimes the DropBox gets in the way when you have multiple windows open for example.

LameXP should hide the Dropbox when a modal dialog pops up. I think there were some improvements in v4.02.

This of course applies only to LameXP's own dialogs. The Dropbox will stay on top of all other apps...

Option to edit destination filenames.

In "Source Files" tab you have the "Title" column, then the "Full Path" column.
Maybe putting a new "Destination File" column between these already existing two, would do the trick.

Renaming the input files is not currently planned. Would require quite some changes - maybe in a later version ;)

Track details window should have FULL bitrate, encoder, etc info just like v3.18 had.

That info is currently not detected in LameXP v4.xx, but I may have a look at this.

If minimized, LameXP goes back to the "Source Files" tab when you open/restore its window.

Not quite sure why that happens, but I can reproduce. Investigating...

If found the cause: The 'show' event is not only triggered when the window is shown, but also when the window is restored!

I have just implemented a workaround. So from now on we only go back to the "Source Files" tab when the window is shown.

Also, when I have the time, I'm looking forward to do a Portuguese (PT-PT) translation for LameXP :cool: :)

New translations are always welcome :)

Please have a look at the translator guidelines before you start:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/Translate.html

Raen

31st May 2011, 18:30

Obviously the first time a folder is accessed there is a delay, because the folder has to be scanned.

If you access the folder again, the info is already in the cache...

That was my thought, but when comparing to v3.18, it is very slow.
When browsing through folders in v3.18, they open instantly, there is no waiting time.

This delay, is it something related to Qt?

Actually the format should be "<Artist> - <Album>.m3u", but only if both, the album artist and the album name, are known.

Are you sure you entered this info on the "Meta Data" tab?

Yes, still LameXP v4.xx is outputting the playlists with "<Album>.m3u" format, the "<Artist> - " part in the filename is missing. Something must be broken along the way.

Only rarely I do not enter an Artist into the "Meta Data" tab, and every time I use LameXP v4 I've to add "<Artist> - " into the M3U filename manually after converting, so I'm sure of this.

LameXP v4.xx offers full Unicode support. Playlists are exported in the UTF-8 format. Probably the extension should be .m3u8 though...

Yes, that's correct. I did a test and converted a track with special characters in the filename and generated a .m3u playlist.
Then tried to run the playlist file and nothing, so I renamed the extension to .m3u8 and it went nicely, recognizing and playing the track.

You should fix this playlist extension problem then ;)

The "genre" field on the "Meta Data" tab is editable, isn't it? :confused:

The available genres are pre-defined. I simply used the ones that are supported by LAME. I think these are the ones defined by ID3.

Yes, it is editable, I meant it more like "writable", just like "Artist" and "Album" meta fields where you can type on them, you are not forced to choose between some pre-defined values or leave it empty.

I use a workaround for this: edit the source files' genre outside of LameXP, and then leave it blank ("unspecified") on LameXP's "Meta Data" tab, it copies the source file's info when converting.

It's just that some genres like "Doom Metal", "Grindcore", etc are not present in the pre-defined list and if one could type them in the field, that would be great.
It was always a thing that bothered me, even in the older releases before v4.xx.

Renaming the input files is not currently planned. Would require quite some changes - maybe in a later version ;)

When you say "Renaming the input files", you are saying "naming output files", right? That was the idea.

LoRd_MuldeR

31st May 2011, 19:02

Build #558 should fix many of your issues:
http://sourceforge.net/projects/lamexp/files/Snapshots%20(BETA)/2011-05-31/

Please note the new context menu in the "Meta Info" dialog window!

That was my thought, but when comparing to v3.18, it is very slow.
When browsing through folders in v3.18, they open instantly, there is no waiting time.

This delay, is it something related to Qt?

Well, it's not related to Qt in general. But to the QFileSystemModel provided by the Qt Framework - which is a bit slow (on Windows).

Of course I could implement my own (stripped down and hopefully faster) Qt-based model for this purpose. But it would be like re-inventing the wheel.

Implementing a file system model unavoidable means that you have to deal with low-level functions of the OS.

Doing this for a single platform (e.g. Windows only) shouldn't be that hard. But the existing QFileSytemModel already works on ALL platforms...

Yes, still LameXP v4.xx is outputting the playlists with "<Album>.m3u" format, the "<Artist> - " part in the filename is missing. Something must be broken along the way.

Only rarely I do not enter an Artist into the "Meta Data" tab, and every time I use LameXP v4 I've to add "<Artist> - " into the M3U filename manually after converting, so I'm sure of this.

I will check this again...

Yes, that's correct. I did a test and converted a track with special characters in the filename and generated a .m3u playlist.
Then tried to run the playlist file and nothing, so I renamed the extension to .m3u8 and it went nicely, recognizing and playing the track.

You should fix this playlist extension problem then ;)

If other applications don't read the file correctly, then I cannot do much.

IMHO these applications should check for the UTF-8 BOM and treat the file like UTF-8, if the BOM is present.

But if changing the file extension helps, I might do.

However people that only know M3U files will surely be confused about M3U8 files ;)

Yes, it is editable, I meant it more like "writable", just like "Artist" and "Album" meta fields where you can type on them, you are not forced to choose between some pre-defined values or leave it empty.

I use a workaround for this: edit the source files' genre outside of LameXP, and then leave it blank ("unspecified") on LameXP's "Meta Data" tab, it copies the source file's info when converting.

It's just that some genres like "Doom Metal", "Grindcore", etc are not present in the pre-defined list and if one could type them in the field, that would be great.
It was always a thing that bothered me, even in the older releases before v4.xx.

I cannot support "custom" genres. As explained above, there are a number of pre-defined genres and you can only choose from these.

AFAIK the OGG and MP4 containers are more flexible here. But plain MP3 files use the more restricted ID3 tags to embed meta info...

See also:
http://pastie.org/private/tef4onaqdxvccj7riuecw

When you say "Renaming the input files", you are saying "naming output files", right? That was the idea.

Correct.

Raen

31st May 2011, 21:48

Thanks for the fast reply and also for the new CUE import wizard, seems to be working flawlessly so far :) Great work!

If other applications don't read the file correctly, then I cannot do much.

IMHO these applications should check for the UTF-8 BOM and treat the file like UTF-8, if the BOM is present.

But if changing the file extension helps, I might do.

However people that only know M3U files will surely be confused about M3U8 files ;)

Well, when I encountered this situation and tried to work around it, I saw that Winamp had an option to save "M3U8 (Unicode)" playlists and figured out the difference between the two extensions.

Maybe if you change this text to "(.m3u8 - Unicode)" maybe people don't get confused about why LameXP is outputting some strange ".m3u8" playlists? :p
http://img638.imageshack.us/img638/3224/unled2xz.th.jpg (http://imageshack.us/photo/my-images/638/unled2xz.jpg/)

EDIT: I was playing some playlists that were created with LameXP v3.18 a while ago and noticed that these playlists, although being .m3u, recognize files with special characters.
So, there must be some difference between the v3.18's .m3u creation method and the v4.xx's.

LoRd_MuldeR

2nd June 2011, 01:53

EDIT: I was playing some playlists that were created with LameXP v3.18 a while ago and noticed that these playlists, although being .m3u, recognize files with special characters.
So, there must be some difference between the v3.18's .m3u creation method and the v4.xx's.

LameXP 3.xx did not support Unicode at all ;)

All strings were simply in the local 8-Bit encoding, i.e. whatever Codepage happened to be configured for Non-Unicode applications on the individual computer.

If you have luck, the 'special character' can be represent in your local 8-Bit encoding, so LameXP 3.xx will be able to display it correctly and save it to the M3U file (again in a local 8-Bit encoding).

And, if you have even more luck, then the other application (e.g. Winamp) will interpret the M3U file with the same local 8-Bit encoding as LameXP and thus will read the 'special character' correctly.

But there is absolutely no guarantee it will work as desired! Also with a local 8-Bit encoding, it is never possible to have characters from different Codepages at the same time...

LameXP v4.xx provides proper Unicode support. Internally everything is represented as Unicode/UTF-16. Only question is: How do we export strings to other programs?

I have now changed the playlist creation in the following way:

* If all file names in the playlist can be represented correctly as Latin-1 (ISO 8859-1) then the M3U file is written as plain Latin-1 text with a '.m3u' extension.

* If there is at least one file name that contains Unicode (Non-Latin1) characters, then the M3U file is written as UTF8-encoded text starting with a BOM and with a '.m3u8' extension.

So can you please try again with Build #560, which is now available via auto-update?

Raen

2nd June 2011, 16:14

Yes, looks like I got some luck with those older playlists, because I found another ones that targeted files that had non-latin characters (cyrillic, japanese, etc) and those didn't play, only the ones that had latin special characters (accents, etc) played.

So can you please try again with Build #560, which is now available via auto-update?

Can you/Will you put the new build also in the Downloads page?
If I can avoid installing, the better, I prefer the portable/zip package ;)

LoRd_MuldeR

2nd June 2011, 19:59

Can you/Will you put the new build also in the Downloads page?
If I can avoid installing, the better, I prefer the portable/zip package ;)

Pre-release builds of LameXP are available from the following location:
http://sourceforge.net/projects/lamexp/files/Snapshots (BETA)/

However in order to get the latest one, you should always run auto-update. I am too lazy to upload every build twice, so the auto-update server is updated more frequently ;)

LoRd_MuldeR

3rd June 2011, 22:26

Today I made a LameXP build with the recent technology preview of Qt v4.8.0:
http://www.mediafire.com/file/xeg7st56wtv5bbw/LameXP.2011-06-03.Release-Static.Build-561.zip

You are welcome to report any regressions or improvements that you may encounter :)

LoRd_MuldeR

4th June 2011, 21:40

LameXP v4.02 Beta-7:

Implemented a custom QFileIconProvider, which (hopefully) makes the "Output Folder" view a bit faster.
Note: This build, in contrast to the one from my previous post, has been made with Qt 4.7.3 again!

codres

5th June 2011, 09:28

I'm getting this error when I try to encode a 5 channel ac3 file to joint stereo. Seems that the resulted wav is aroung 5Gb. Maybe because the huge size ?

LameXP v4.01 (Build #418), compiled at 2011-04-04

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

C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/9d3c8ffa6eec43b295a520c4348c6d49/tool_valdec.exe "H:\Bietul Ioanide.1979 T01 3_2ch 448Kbps DELAY 0ms.ac3" -w F:\\c8e18d6f24704bd6bca7dae03f4a1902.wav

Opening audio output PCM16 3/2.1 (5.1) 48000...
---------------------------------------
Frames/errors: 264865/0
System time: 128594ms
Process time: 126578ms
Approx. 1.49% realtime CPU usage

Exited with code: 0x0000

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

C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/9d3c8ffa6eec43b295a520c4348c6d49/tool_sox.exe -V3 -S --guard --temp . F:\\c8e18d6f24704bd6bca7dae03f4a1902.wav -c2 F:\\78d55f307e5549c7b3e0f551cafc1926.wav

C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\9d3c8ffa6eec43b295a520c4348c6d49\tool_sox.exe: SoX v14.3.2
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\9d3c8ffa6eec43b295a520c4348c6d49\tool_sox.exe FAIL formats: can't open input file `F:\\c8e18d6f24704bd6bca7dae03f4a1902.wav': WAVE: RIFF header not found

Exited with code: 0x0002

LoRd_MuldeR

5th June 2011, 13:01

Wave/RIFF files cannot exceed a size of 4 GB. That's a limitation of the RIFF file format, because the size field is 32-Bit :rolleyes:

As far as I know, ValibDec will create a RF64 file, if the size exceeds 4 GB. Unfortunately most tools, including SoX, do NOT support RF64 files yet...

(Indeed there is no RIFF header in this case, only a RF64 header)

codres

5th June 2011, 13:41

Ok, thanks for clearing some things. I manage to reencode the file with eac3to.

LoRd_MuldeR

5th June 2011, 20:35

LameXP v4.02 RC-1:

Last chance to report bugs that you don't want to see in the next release version ;)

Chimel

11th June 2011, 01:56

Not a bug, but a suggestion to simplify the Add File(s)/Folder features:
Why not combine them into a single Add Files button and let the user browse and select either files or a folder?
Maybe with a "Add recursively" checkbox in the Browse dialog box when a folder is selected.

Personally I use only the "File|Open Folder Recursively" menu, it's been a bit disappointing to see the Add Folder button disappear. That's why it would be great to be able to select either files or folders from the same button in the main UI, I don't really understand why there needs to be 3 different menu items to add files. And if it's a folder, the recursive checkbox should be selected by default. Very low priority, I just thought it would improve usability and be easier to maintain just one Add feature too.

There's one little bug that bothers me, although I'm sure it's meant to be by design: When adding files, for instance a large recursive folder, each of the file names is displayed on the forefront in the middle of the screen, so you can't switch to another app like a browser or video player while it's adding the files. Which in my case took 3 minutes for over 400 files (I had another CPU-intensive app running at the same time.)
Is it possible to display the file names only if the app in focus is LameXP?

FYI, this is how I use LameXP: Usually once a week I rip my new CDs with WMP into lossless WMAs, takes about 2 minutes per CD max. Then I move all the CD folders into a single folder outside the WMP library and run LameXP on this folder recursively. Then the MP3s are moved to a separate folder where I can pick them up for mobile usage, the WMAs are moved back to the WMP library. I use robocopy /mov and /move to keep the same structure. If I could specify the folder to add as a parameter, everything could be scripted.

LoRd_MuldeR

11th June 2011, 02:48

Not a bug, but a suggestion to simplify the Add File(s)/Folder features:
Why not combine them into a single Add Files button and let the user browse and select either files or a folder?
Maybe with a "Add recursively" checkbox in the Browse dialog box when a folder is selected.

Personally I use only the "File|Open Folder Recursively" menu, it's been a bit disappointing to see the Add Folder button disappear. That's why it would be great to be able to select either files or folders from the same button in the main UI, I don't really understand why there needs to be 3 different menu items to add files. And if it's a folder, the recursive checkbox should be selected by default. Very low priority, I just thought it would improve usability and be easier to maintain just one Add feature too.

A combined "add files/folder" feature would be hard to implement, because there are distinct "open" dialog boxes for selecting files and folders.

However you may add folders via drag&drop. The "drop box" may also be helpful here...

There's one little bug that bothers me, although I'm sure it's meant to be by design: When adding files, for instance a large recursive folder, each of the file names is displayed on the forefront in the middle of the screen, so you can't switch to another app like a browser or video player while it's adding the files. Which in my case took 3 minutes for over 400 files (I had another CPU-intensive app running at the same time.)
Is it possible to display the file names only if the app in focus is LameXP?

Not currently.

FYI, this is how I use LameXP: Usually once a week I rip my new CDs with WMP into lossless WMAs, takes about 2 minutes per CD max. Then I move all the CD folders into a single folder outside the WMP library and run LameXP on this folder recursively. Then the MP3s are moved to a separate folder where I can pick them up for mobile usage, the WMAs are moved back to the WMP library. I use robocopy /mov and /move to keep the same structure. If I could specify the folder to add as a parameter, everything could be scripted.

Currently individual files can be added via command-line using "--add <filename>".

Shouldn't be too hard to add "--add-folder <folder>" and "--add-recursive <folder>" options in one of the next versions.

LoRd_MuldeR

11th June 2011, 19:04

LameXP v4.02 RC-3:

Added "--add-folder <path>" and "--add-recursive <path>" command-line switches.

phideaux3

13th June 2011, 08:04

LoRd_MuldeR

13th June 2011, 14:12

First, just wanted to say how much I appreciate your having created this tool and continuing to maintain it. I've been using it for a few years and think it's got to be the best for my needs.

In an earlier comment, you said “try again with Build #560, which is now available via auto-update” – not sure what you meant by this. Should I be able to run ‘Check for Updates’ from the app and it should grab the new build? If so, it didn’t work. It kept saying 418 was the latest.

Currently "final" builds (such as v4.01 Final, Build #418) will only check for new stable releases. Only "beta" (pre-release) builds are able to check for new "beta" releases. So if you are currently using a "stable" version, you will have to update to a later "pre-releae" build manually, before the Auto-Update mechanism will find even newer "pre-release" builds. However the upcoming v4.02 stable release version will contain an option to check for "beta" (pre-release) updates - this option will be disabled by default.

Anyway, the reason I came to this forum was because 418 kept crashing my system (W7Usp1 64-bit). I was encoding to mp3 it on a quad-core with a queue of over 2k files. I reduced the threads to 3, and it didn’t crash, but over 50% of the encodes failed with error code 3 or 5 and a very small or zero-byte mp3 file.

I installed Build 574 and reduced the queue to fewer than 600 and left threads at 3. The app died with “Unhandled exception error, application will exit.” after 313 files completed.

It's hard to tell what exactly caused the crash. Do you know how to make a "debug" build and run it in a debugger?

Also: Did you watch the memory usage (Private Bytes) of the LameXP process (e.g. in ProcessExplorer). Did it increase to ~2 GB just before the crash?

I just ran an encode with 800+ files on my system (Win7 x64, Core2 Quad, 4 GB of RAM, 4 threads) and everything ran through just fine.

Also the memory usage (Private Bytes) ware relatively constant at around ~55 MB. So this definitely is not a 'memory leak' problem!

I ran another queue of about 250 files, all finished except two, which failed with

PROCESS TIMEOUT !!!
Exited with code: 0xF291

Re-ran those two after that queue finished and they encoded fine.

Process timeout means that one of the encoder/decoder processes didn't complete (or at least send an update message) in time.

This can happen when the process encounters a deadlock. But it can also happen if the process didn't get enough CPU time by the OS to do its job.

Did you run other CPU intensive applications in the background ???

Is there a way to start the binary with a flag to disable the startup ‘Your version is too old’ check and dialog? If so, any guesses as to the version(s) to support such capability? I wasn’t having these kinds of problems with queues over 1000 with previous versions. Though I’d bet the queue size isn’t the problem, it just increases the likelihood of a problem in any given job.

With "previous versions" you mean v4.00 or v3.xx? Actually v4.xx is a completely new application, compared to v3.xx.

Also you can disable the update-reminder in the options menu. However extremely old versions will start to "force" the update at some point.

This can't be skipped (and usually shouldn't be skipped), except by compiling LameXP from the sources yourself and removing the check.

It is discouraged to use v3.xx nowadays, because there were a lot of nasty limitations (the lack of Unicode support is probably the worst of them).

But after all this is OpenSource software. So you can always modify the application according to your needs...

Is there a way to have the debug log sent to a file as well as to the console? Is there a way to retain encode logs? All this info seems to be gone after a crash.

Not currently. You can Copy&Paste the text from the console or the encode log and then save it to file (e.g. with Notepad).

But you are right. This won't be possible if the application crashed - which usually shouldn't happen :p

Also, the ‘Output Directory’ tab is still quite slow to respond. Changing to that tab is quicker than before, but you have to wait a bit (on the order of 60 seconds or so) before you can do anything or even switch to another tab.

This has been discussed before. For me it generally takes less than ~5 seconds.

But that probably depends on the "size" (number of files and sub-directories) of the initial output directory.

And of course slow Anti-Virus software might slow things down a lot here! Try to temporarily disable your real-time Anti-Virus scanner - just for testing.

There's not much I can do to make it faster, as the QFileSystemModel is a part of Qt. Already tried a number of workarounds to make it a bit faster.

I once made a test build with the Tech-Preview of Qt v4.8, which might (or might not) give some improvement. Did you check that (http://forum.doom9.org/showpost.php?p=1505321&postcount=285) one out?

Lastly, my wish list of future features:
(1) Default for drag-&-drop should be recursive (maybe an option setting?).
(2) An option to designate default action when encoding: whether to overwrite, create a new file, or query the user.
(3) After adding folders, the message could be a little more descriptive as to the count of files rejected for specific reasons (not an audio file, corrupted file).
(4) Option for more columns in the main pre-processing window (file type, size?) and sortability
(5) Ability to sort by status in the Processing window

(1) Default definitely shouldn't be recursive, I think. That's because recursively adding a directory tree might add a HUGE number of files and take a very long time, which probably isn't intended by the user. But making this an option sounds like a feasible idea.

(2) Asking the user every time the output file already exists doesn't fit very well into the "batch processing" concept of LameXP. However adding an "overwrite existing files" option would be possible, but dangerous. Maybe when I implement an option to re-name the output files.

(3) Well, how do we know what is the reason? If the type of the file couldn't be determined, is this because it's a file type we simply don't know/support or is this a broken file? It's impossible to know. After all we can only reject everything that doesn't seem proper...

(4) Not quite sure. The "size" of the input file currently is not detected (although it would be easy to add). And "file type" is a bit vague (container format? audio format? detailed compression info?). But adding some "sort" options (at least 'by filename' and 'by title') to the Source Files tab is on my TODO list.

(5) Not currently possible, as jobs are appended to the list as they are created. Might be easier to do than I thought at first.

LoRd_MuldeR

13th June 2011, 20:18

LameXP v4.02 RC-4:

An attempt to make LameXP deal better with a large number of files (will only show the most recent 50 files in the progress view now).

phideaux3

13th June 2011, 23:25

Thanks for the quick and informative reply.

Currently "final" builds (such as v4.01 Final, Build #418) will only check for new stable releases. Only "beta" (pre-release) builds will are able check for new "beta" releases.

Of course. Makes sense.

It's hard to tell what exactly caused the crash. Do you know how to make a "debug" build and run it in a debugger?

Not really. Unless you count shell scripting, I haven't coded since before the introduction of WNT. If there's a doc on how to do it you could point me to, I might try.

Also: Did you watch the memory usage (Private Bytes) of the LameXP process (e.g. in ProcessExplorer). Did it increase to ~2 GB just before the crash?

I just ran an encode with 800+ files on my system (Win7 x64, Core2 Quad, 4 GB of RAM, 4 threads) and everything ran through just fine.

Also the memory usage (Private Bytes) ware relatively constant at around ~55 MB. So this definitely is not a 'memory leak' problem!

Didn't notice, but your assessment sounds accurate. I was watching Memory Usage in Task Manager, it seemed to hover just over 2G for the entire system, but I wasn't watching right before the crash.

Process timeout means that one of the encoder/decoder processes didn't complete (or at least send an update message) in time.

This can happen when the process encounters a deadlock. But it can also happen if the process didn't get enough CPU time by the OS to do its job.

Did you run other CPU intensive applications in the background ???

Not that I can think of. Firefox? Outlook? CPU performance was floating just under 100% with three threads.

I've been running some more tests, and I was getting the PROCESS TIMEOUT quite often -- as early as the 14th and 20th file in the queue. (Private RAM approaches but never gets to 37MB.) I decreased the threads to two, and over 100 files have now completed without problem. The odd thing to me is that this never happened w/ the previous version (I think I was using the Xmas build on this same system for quite a while.)

(1) Default definitely shouldn't be recursive, I think. That's because recursively adding a directory tree might add a HUGE number of files and take a very long time, which probably isn't intended by the user. But making this an option sounds like a feasible idea.

Not making it the default makes sense -- as long as it's an option.

(3) Well, how do we know what is the reason? If the type of the file couldn't be determined, is this because it's a file type we simply don't know/support or is this a broken file? It's impossible to know. After all we can only reject everything that doesn't seem proper...

I guess I was supposing that you could ignore files by extension. Doesn't seem to make sense to attempt to load an md5, for instance. Maybe this functionality could be an option -- "Loadable file types"?

(4) Not quite sure. The "size" of the input file currently is not detected (although it would be easy to add). And "file type" is a bit vague (container format? audio format? detailed compression info?). But adding some "sort" options (at least 'by filename' and 'by title') to the Source Files tab is on my TODO list.

Cool. Re: "file type", same supposition as before. My goal would be that if I toss in some folders which already have some mp3's in them, I'd like to not waste the time re-encoding them.

I forgot another wish list item, which would be to be able to select multiple items in the list (shift and/or ctrl keys) and remove all selected. Am I correct that currently it's only possible to remove one at a time?

(5) Not currently possible, as jobs are appended to the list as they are created. Might be easier to do than I thought at first.

I think you can see the value in being able to sort the results and have all the failures grouped together.

Thanks again!!!

LoRd_MuldeR

14th June 2011, 00:05

Not really. Unless you count shell scripting, I haven't coded since before the introduction of WNT. If there's a doc on how to do it you could point me to, I might try.

You'd have to install Visual Studio (I think one of the free Express (http://www.microsoft.com/express/Downloads/#2010-Visual-CPP) editions does the job), compile yourself a "Debug" build and start debugging. This way it will switch over to the debugger on crash (and show you the line in code where it crashed) instead of just throwing an error message. If you never used an IDE, like Visual Studio, before, then it will need some familiarization though. Depends on how much time you are willing to spend. Note that there are some basic compile instructions in the LameXP FAQ document (you will need to install Qt as well).

Didn't notice, but your assessment sounds accurate. I was watching Memory Usage in Task Manager, it seemed to hover just over 2G for the entire system, but I wasn't watching right before the crash.

Well, the global memory usage doesn't say much. Even if all physical RAM is in use, the OS can still use the swap file on the HDD to allocate more memory.

If there is some problem with memory, then it's the 2 GB per process memory limit. A single 32-Bit process cannot allocate more then 2 GB of memory, no matter what.

But it doesn't seem to be a problem with LameXP. Even when processing hundreds of files at once, memory usage for the LameXP process stays below ~60 MB.

Not that I can think of. Firefox? Outlook? CPU performance was floating just under 100% with three threads.

Well, the goal is to have ~100% CPU usage, i.e. not waste any CPU cycles idle.

That's why we create/run several threads in parallel. If CPU usage drops below 100%, it means the CPU or at least some of its cores were idle some of the time.

If, however, there are some (high priority) processes that "eat" too many CPU cycles, it can happen that LameXP's encoder processes starve and eventually trigger a timeout.

Note that LameXP's encoder processes are running with reduced priority. This is done in order to keep the system responsive while encoding...

I've been running some more tests, and I was getting the PROCESS TIMEOUT quite often -- as early as the 14th and 20th file in the queue. (Private RAM approaches but never gets to 37MB.) I decreased the threads to two, and over 100 files have now completed without problem. The odd thing to me is that this never happened w/ the previous version (I think I was using the Xmas build on this same system for quite a while.)

That is really strange. I never get that. Not one single time. And you are the first user to complain about this issue.

I'm not quite sure what I can do, except for increasing the timeout interval. But it already is 30 seconds.

If the encoder process doesn't respond (i.e. either complete or send a progress update) within 30 seconds, something has to be seriously wrong...

Also with the old 3.xx versions you couldn't get a timeout error, simply because there wasn't any timeout check implemented ;)

(If one of the encoder processed deadlocked, LameXP v3.xx would have waited until forever...)

I guess I was supposing that you could ignore files by extension. Doesn't seem to make sense to attempt to load an md5, for instance. Maybe this functionality could be an option -- "Loadable file types"?

No, we cannot use file extensions. File extensions are neither unambiguous nor reliable. Guessing the file's type form its "extensions" is the most stupid way to implement this.

LameXP does it properly: It uses MediaInfo to actually analyze the file and detect the file's type from it's content. The file's name (including its extension) is not considered at all.

I forgot another wish list item, which would be to be able to select multiple items in the list (shift and/or ctrl keys) and remove all selected. Am I correct that currently it's only possible to remove one at a time?

I will look for a solution.

I think you can see the value in being able to sort the results and have all the failures grouped together.

Yes. If you encoded a huge number of files and only a few failed, it will be hard to find those on the list...

phideaux3

14th June 2011, 08:15

Ran another set of files with only two threads.

2 of 1587 files failed with

PROCESS TIMEOUT !!!
Exited with code: 0xF291

One failed running tool_lame.exe, one didn't get past tool_flac.exe.

I can only guess from that low-prio jobs are getting pushed back at peak times and having to wait longer than the timeout. Any chance of making the timeout another option? Maybe a range of up to 5 minutes? It would seem that when I used the older version, nothing (thanfully) ever deadlocked, but because there was no timeout, nothing ever failed for that reason.

PS - max private RAM consumed with that queue was <53MB.

:thanks:

LoRd_MuldeR

14th June 2011, 12:03

Still, unless you are running other CPU intensive tasks in parallel to LameXP there shouldn't be any problem. And even if you are running CPU intensive processes in parallel to LameXP and these processes have an increased priority, then the OS' scheduler shouldn't let the encoder processes starve. They might get less CPU time than the higher priority processes, yes. They might have to wait a few seconds now and then, yes. But more than 30 seconds? That's definitely too much. The only situation in which a process (one that is not in the "idle" priority class) might starve is when there's another processes running with "real time" priority and that processes uses the CPU all the time. But that's the reason why using the "real time" priority class is highly discouraged - especially for CPU intensive tasks. So either there is something seriously wrong with your system (did you install any CPU "tweak" or "optimization" tools?) or there's another problem that we didn't consider so far. Last but not least: Did you try to disable the real-time scanner (guard) of your Anti-Vrius software? It wouldn't be the first time that it turns out an Anti-Virus scanner caused all the trouble...

(Anyway, I will increase the timeout to 3 minutes. I don't want to have yet another option. Will send you the new build via PM soon!)

Raen

14th June 2011, 16:06

I have now changed the playlist creation in the following way:

* If all file names in the playlist can be represented correctly as Latin-1 (ISO 8859-1) then the M3U file is written as plain Latin-1 text with a '.m3u' extension.

* If there is at least one file name that contains Unicode (Non-Latin1) characters, then the M3U file is written as UTF8-encoded text starting with a BOM and with a '.m3u8' extension.

So can you please try again with Build #560, which is now available via auto-update?

Tried Build #576 and it is working correctly now, exactly as you described ;)

Also, the "<Artist> - <Album>" playlist naming format is working again ;)

:thanks:

LoRd_MuldeR

14th June 2011, 18:55

LameXP v4.02 Final :)
https://github.com/lordmulder/LameXP/downloads

Changes between v4.01 and v4.02:
* Upgraded build environment to Microsoft Visual Studio 2010
* Dropping support for Windows 2000 and Windows XP RTM. Windows XP needs (at least) Service-Pack 2 now!
* Added Cue Sheet import wizard, which allows splitting and importing tracks from Cue Sheet images
* Added ATSC A/52 (AC-3) encoding support, based on Aften encoder v0.0.8+ (Git Master)
* Added Avisynth input (audio only!) using 'avs2wav' tool, partly based on code by Jory Stone
* Added a method to use custom tools instead of the "built-in" ones (see FAQ doc for details)
* Added an option to copy all meta information of a single file over to the "meta information" tab
* Added two new command-line switches: "--add-folder <path>" and "--add-recursive <path>"
* Added one new translation: Korean
* Updated Qt runtime libraries to v4.7.3
* Updated LAME encoder to v3.99.1.0 (2011-04-15), compiled with ICL 12.0.3 and MSVC 10.0 (details)
* Updated Vorbis encoder to v2.87 using aoTuV Beta-6.03 (2011-05-04), compiled with ICL 11.1 and MSVC 9.0
* Updated mpg123 decoder to v1.13.3 (2011-04-21), compiled with GCC 4.6.0
* Updated MediaInfo to v0.7.45 Beta (2011-05-02), compiled with ICL 12.0.3 and MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Fixed placement of the Dropbox when the Taskbar is located on the top or on the left side
* Improved playlist generation: Generate M3U (Latin-1) or M3U8 (UTF-8) playlist file as required
* Only show the most recent 50 items in the "processing" window (for better performance)
* Miscellaneous bugfixes

Przemek_Sperling

16th June 2011, 06:47

nautilus7

16th June 2011, 10:02

I'm trying to encode a 5.1 file using avs input.

My script plays fine in mpc:
l=WAVSource("l.wav")
r=WAVSource("r.wav")
c=WAVSource("c.wav")
lfe=WAVSource("lfe.wav")
ls=WAVSource("ls.wav")
rs=WAVSource("rs.wav")

MergeChannels(l,r,c,lfe,ls,rs)

Lame-xp fails with this error massage:
LameXP v4.02 (Build #578), compiled at 2011-06-14

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

C:/Users/NAUTIL~1/AppData/Local/Temp/d2d906dac226430bb5d0fee4458f206d/tool_avs2wav.exe C:\sintel\sintel-master-51-flac\51.master.avs C:\Users\NAUTIL~1\AppData\Local\Temp\d2d906dac226430bb5d0fee4458f206d\e36981fe6dde42c2bb51452c114e12c5.wav

avs2wav v1.2 [May 24 2011]
by Jory Stone <jcsston@toughguy.net>, updates by LoRd_MuldeR <mulder2@gmx.de>
Input: C:\sintel\sintel-master-51-flac\51.master.avs
Output: C:\Users\NAUTIL~1\AppData\Local\Temp\d2d906dac226430bb5d0fee4458f206d\e36981fe6dde42c2bb51452c114e12c5.wav
Checking Avisynth...
Done
Analyzing input file...
Done
Opening output file... Done
[Audio Info]
TotalSamples: 42624000
TotalSeconds: 888
SamplesPerSec: 48000
BitsPerSample: 16
Channels: 6
AvgBytesPerSec: 576000
Dumping audio data, please wait:
AVIStreamRead succeeded, but did not return any samples!
Failed to dump audio stream (status -4). Terminating!

Exited with code: 0xFFFFFFFC

manolito

17th June 2011, 00:36

* Added ATSC A/52 (AC-3) encoding support, based on Aften encoder v0.0.8+ (Git Master)
Beautiful, now I can finally get rid of HeadAC3HE...

Did a couple of test conversions, everything is cool. Still slow when selecting the target folder, but I know I should direct my complaints about that to the Qt developers :devil:

Thanks very much

Cheers
manolito

casio7131

17th June 2011, 14:29

lamexp review: http://www.betanews.com/article/LameXP-A-great-audio-encoder-by-any-other-name/1308263706

spida_singh

17th June 2011, 18:39

My little brother updated this and did not accept the license, re-installed, still the samwe message, how do i bring up the option to accept the license...as the app just exits afterwards...

regards

boyumeow

18th June 2011, 04:53

User/AppData or Registry, I think...

mariush

18th June 2011, 05:05

See my post and the answer below the post: http://forum.doom9.org/showthread.php?p=1473682#post1473682 - basically the configuration file remains... in my case it was: C:\Documents and Settings\Administrator\Local Settings\Application Data\LoRd_MuldeR\LameXP - Audio Encoder Front-End\config.ini

Delete config.ini or the whole folder, run setup again and you're all set.

LoRd_MuldeR

18th June 2011, 09:35

Thank you! This version works much better than the previous one.

I have a question concerning the cue sheet wizard. Can you make the wizard be able to compress the images to any file format (Vorbis, mp3, etc.) and put it to the same location as cue sheet files? I noticed that the wizard decompresses files to separate wavs and demands to show save folder manually.

It's necessary to split the source Wave (or whatever) file into individual Tracks (Waves files) according to the Cue Sheet prior to encoding.

The output folder defaults to "<folder where the cue file is located>\<name of the cue file without extension>".

Once the tracks have been imported (i.e. added to source file list) you can compress them to all output formats currently supported in LameXP.

And of course you may use the option "Save output files to the same folder where the input file located".

Lame-xp fails with this error massage:
Checking Avisynth...
Done
Analyzing input file...
Done
Opening output file... Done
[Audio Info]
TotalSamples: 42624000
TotalSeconds: 888
SamplesPerSec: 48000
BitsPerSample: 16
Channels: 6
AvgBytesPerSec: 576000
Dumping audio data, please wait:
AVIStreamRead succeeded, but did not return any samples!
Failed to dump audio stream (status -4). Terminating!

This error message indicates that AVIStreamRead() returned with success, but the number of samples returned was zero!

I don't think this should ever happen. It should either fail or return at least one sample (usually a much higher number of samples).

Indicating success but returning no samples doesn't make much sense to me. Smells like a bug in VFW or Avisynth? :confused:

The logic of avs2wav is quite simple: We continuously call AVIStreamRead(), as long as it succeeds, and dump all samples.

Failure of AVIStreamRead() indicates the end of the stream. Nonetheless I added the "number of samples" check to prevent livelocks.

Otherwise, if AVIStreamRead() succeeds with zero samples returned, we'd keep on calling it without ever making any progress.

(BTW: I successfully dumped a few 5.1 sources with avs2wav on my system)

lamexp review: http://www.betanews.com/article/LameXP-A-great-audio-encoder-by-any-other-name/1308263706

:thanks:

My little brother updated this and did not accept the license, re-installed, still the samwe message, how do i bring up the option to accept the license...as the app just exits afterwards...

You can delete "C:\Users\John Doe\AppData\Local\LoRd_MuldeR\LameXP - Audio Encoder Front-End\config.ini", either manually or via the un-installer.

Alternatively you could open "config.ini" file in Notepad (or your favorite code/text editor) and change the LicenseAccepted=-1 line to LicenseAccepted=0.

Note: There may be several such lines in the INI file. Make sure you edit the line within the INI section for the current LameXP version!

cengizhan

21st June 2011, 10:56

there is problem with panda cloud antivirus. when the antivrus is active lamexp says tool_xxx.exe can not be locked and then quits.

LoRd_MuldeR

21st June 2011, 11:35

there is problem with panda cloud antivirus. when the antivrus is active lamexp says tool_xxx.exe can not be locked and then quits.

Well, if "panda cloud antivirus" (whatever that is) stops innocent software from working correctly, then there obviously is a serious bug in that product.

So if you want the bug fixed, I suggest you contact their support team! We cannot help you here with problems induced by proprietary third-party software :rolleyes:

And, if they don't fix the issue (in due time), switch to another anti-virus product. One that doesn't prevent innocent software from functioning...

(There are enough good alternatives available for free. Microsoft Security Essentials (http://www.microsoft.com/en-us/security_essentials/default.aspx) and Avira AntiVir Personal (http://www.avira.com/en/avira-free-antivirus), just to name two products that I use)

See also:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#96205e91

cengizhan

21st June 2011, 16:38

Thanks. that worked.

LoRd_MuldeR

21st June 2011, 16:41

Thanks. that worked.

Sorry, what exactly did work? :confused:

cengizhan

23rd June 2011, 08:35

Sorry, what exactly did work? :confused:

the version that you have send with a pm works with panda.

LoRd_MuldeR

23rd June 2011, 14:30

the version that you have send with a pm works with panda.

So it seems "panda cloud antivirus" indeed holds an exclusive lock on the file and forbids other applications to access the file until it is done with whatever it is doing :rolleyes:

It's a common problem that anti-virus software can significantly delay file access, yes. But completely denying access to files that normally would be accessible is prone to causing serious trouble! :mad:

(The new workaround (http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-06-26/) should be able to deal with this situation, but it can slow down the LameXP startup speed even more - on affected systems)

LoRd_MuldeR

2nd July 2011, 16:33

LameXP v4.03 Alpha-2:

This version fixes a silly bug in the Cue Sheet importer which caused tracks to be skipped, if the title contained certain characters (like \, / or ?).

Dogway

4th July 2011, 06:54

-choose output container mp4/aac
-option to cancel encode if temporal drive is less than 2Gb
-Some pop out calltips over parameters (I can help translating this to Spanish)
-Normally to rip my music CD's I use CDex, and its mainly because its CDDB option, so maybe CD Ripping option plus CDDB?
-Maybe some better organisation in the parameters tab, its difficult to see what options belongs to which format and what are general.
-Typo in Show Dropbox in Spanish would be "Mostrar DropBox"

Well they are some little observations. I like your program so keep going!

LoRd_MuldeR

4th July 2011, 07:44

-choose output container mp4/aac

We are using the Nero AAC encoder, which can only output AAC in an MP4 container. It doesn't output ADIF or ADTS files.

MP4Box could be integrated to extract the AAC streams from the MP4 container afterwards, but is this worth the effort?

-option to cancel encode if temporal drive is less than 2Gb

There already should be a warning, if the free space in the TEMP folder gets too low. And you can abort then, if you want.

(Of course you can abort at any time)

-Some pop out calltips over parameters (I can help translating this to Spanish)

Suggestions? What info should be added where? Cannot be done in the F.A.Q document?

-Normally to rip my music CD's I use CDex, and its mainly because its CDDB option, so maybe CD Ripping option plus CDDB?

CD ripping is a bit out of scope. I really do not want to re-invent the wheel. Therefore I would recommend EAC (Exact Audio Copy).

(If they only had a CLI interface, I would integrate EAC)

-Maybe some better organisation in the parameters tab, its difficult to see what options belongs to which format and what are general.

Suggestions? ;)

-Typo in Show Dropbox in Spanish would be "Mostrar DropBox"

Feel free to update the language file according to the translator's guide:
http://mulder.brhack.net/public/doc/lamexp_translate.html

Dogway

4th July 2011, 08:16

Wow I never saw a so ungrateful reply. I should consider post only when I got problems and not for helping anymore.

We are using the Nero AAC encoder, which can only output AAC in an MP4 container. It doesn't output ADIF or ADTS files.

MP4Box could be integrated to extract the AAC streams from the MP4 container afterwards, but is this worth the effort?
I have a bat for demuxing mp4 containers. Do I care that much? No. Do they? Wait for replies...

Suggestions? What info should be added where? Cannot be done in the F.A.Q document?
For example that HC is for low bitrate, LC is for High bitrate, that Joint Stereo is for compression, doesn't affect quality. Top quality (slowest) con sometimes be counterproductive.
If you care enough to make a program for newbies/lazy asses (LameXP doesn't do anything that is not possible alternatively) at least dont make them visit FAQ.

CD ripping is a bit out of scope. I really do not want to re-invent the wheel. Therefore I would recommend EAC (Exact Audio Copy).

(If they only had a CLI interface, I would integrate EAC)
If CD Ripping is out-of-scope, and movie audio encoding barely is too, what is the scope of this software? AFAIK the most common way you can get audio files are from DVD,Bluray,CD.

Suggestions? ;)
I was going to suggest you something, like dynamic building the last tab upon the format chosen in the previous tab. That is; hiding unnecesary parameters.

Feel free to update the language file according to the translator's guide:
http://mulder.brhack.net/public/doc/lamexp_translate.html
Sorry, Im not going to hassle with all that. Id rather prefer if the program defaulted to English. I don't like programs in other languages.

LoRd_MuldeR

4th July 2011, 10:18

Wow I never saw a so ungrateful reply. I should consider post only when I got problems and not for helping anymore.

Really :confused:

(Maybe you should consider that I also have a real-life job and lectures/exams, so I don't always have the time to write lengthy posts)

I have a bat for demuxing mp4 containers. Do I care that much? No. Do they? Wait for replies...

Well, of course you can demux the AAC stream from the MP4 container using a batch script.

The question is: Do we need this functionality in LameXP? What is the purpose of having a "raw" (actually ADIF or ADTS) AAC stream?

And should we encourage people to create .aac files instead of MP4 files? AFAIK MP4 files are much more common.

(The only reason to demux the AAC stream that I can think of is for remuxing in the next step. Which will need other software anyway)

For example that HC is for low bitrate, LC is for High bitrate, that Joint Stereo is for compression, doesn't affect quality. Top quality (slowest) con sometimes be counterproductive.
If you care enough to make a program for newbies/lazy asses (LameXP doesn't do anything that is not possible alternatively) at least dont make them visit FAQ.

Both, the AAC profile and the LAME channel mode, should work okay with the default settings (i.e. let the encoder pick the right option).

Changing the default option should not be needed most of the time. And if somebody overwrites the default, he/she should have a reason to do so.

I could add a short summary in the form of a tool tip. Still a more thorough explanation in the F.A.Q may be preferable...

If CD Ripping is out-of-scope, and movie audio encoding barely is too, what is the scope of this software? AFAIK the most common way you can get audio files are from DVD,Bluray,CD.

The scope of this software obviously is converting audio files. Essentially it's still a GUI to a number of CLI audio encoders and decoders.

I certainly will not write yet another CD ripper. It wouldn't be trivial to write a good/robust CD ripper and good solutions already exits (e.g. EAC).

If, however, there was an OpenSource CD ripper available that can be integrated into LameXP (preferably as a CLI tool), I'd have a look...

I was going to suggest you something, like dynamic building the last tab upon the format chosen in the previous tab. That is; hiding unnecesary parameters.

I think options appearing/disappearing on the "Advanced Options" tab, depending on what encoder is selected at the "Compression" tab is very confusing. In the old LameXP 3.xx I disabled (grayed out) options that didn't apply to the selected encoder. But after a while I noticed that it's more annoying/misleading than helpful. So I did not implement it in version 4.xx. However the options on the "Advanced Options" tab may be reordered in a more plausible way (the currently are arranged in the order in which they were added, more or less). I am open for ideas here...

Sorry, Im not going to hassle with all that. Id rather prefer if the program defaulted to English. I don't like programs in other languages.

Well, you can always switch to English. LameXP will still default to the system's language though (if available in LameXP), because I think it's better that way for most users (not everybody speaks English, but we can expect the the user understands his system's language).

If, however, you are still interested in improving the Spanish translation, I can only point you to the existing language file and the translators guide. There shouldn't be much of a hassle. The Qt Linguist toll is straight forward to use and the translators guide has all info you should need.

(I cannot maintain any language files, except for the English and German ones, myself. So the project relies on the contributors for multi-language support)

Dogway

4th July 2011, 10:46

You have the arguments, fair enough and plausible, not the manners tho, specially when I just pinpoint small quirks that can be helpful for further development.

In relation to aac, I always used this format, although I know mp4 is just a container I just leave it for video. In this way I can know at a glance what do I have and what I am going to play. m4a can be an alternative.

Reorganizing the panel was my first idea. Maybe just enclosing paramaters in a title linebox for mp3, ogg, aac, etc All I wanted to say is it was hard to read...

LoRd_MuldeR

6th July 2011, 23:19

New build available:

Updated URL of the official web-site that is used in the program, as the old domain seems lost.

(The update system is not effected, as it always was designed to use several mirrors)

Taurus

7th July 2011, 16:13

New build available:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-07-06/

Updated URL of the official web-site that is used in the program, as the old domain seems lost.

(The update system is not effected, as it always was designed to use several mirrors)
Just downloaded the test version shown above.
The installer hangs/does nothing after getting the install path.
From within LameXP updater no new updates are shown:mad::p

LoRd_MuldeR

7th July 2011, 16:41

Just downloaded the test version shown above.
The installer hangs/does nothing after getting the install path.

Hmmm, nothing with the installer changed recently :confused:

There was a minor change on 2011-06-10 just before the v4.02 release. And before that a change on 2011-04-14.

Can you reproduce the issue? And, if so, can you give any hint on how to re-produce it?

(Runs through for me just fine)

Okay, I can re-produce the crash under Windows XP (http://img850.imageshack.us/img850/9316/clipboard49.png) (didn't happen on Windows 7). And I think it's the LockedList plugin-in.

From within LameXP updater no new updates are shown:mad::p

Correct. The latest version currently distributed over auto-update is v4.02 Final.

Taurus

7th July 2011, 17:54

No crash on my side, just a silent bye, bye without any trace.
Will try 595 in a minute.
And yes, WinXp 32bit here.
Edit: yes 595 is running, of course without installer....

LoRd_MuldeR

7th July 2011, 18:00

New build available:

Reverted the LockedList plug-in to v2.3, as the latest v2.4 seems to cause installer crashes on Windows XP.
I also report the problem to the author of the LockedList plug-in. Let's see what happens...

Taurus

7th July 2011, 18:21

New build available:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-07-09/

Reverted the LockedList plug-in to v2.3, as the latest v2.4 seems to cause installer crashes on Windows XP.
I also report the problem to the author of the LockedList plug-in. Let's see what happens...
And yes, the new version is doing fine.
Thank you, you're amazing :):p:thanks:

LoRd_MuldeR

11th July 2011, 19:45

New build available:

Now again using an up-to-date LockedList plug-in for the installer, as the author has fixed the crash on Windows XP (32-Bit).

manolito

14th July 2011, 00:04

Can LameXP convert a 5.1 AC3 to a stereo WAV file? If so, I am too stupid to find the right setting.

If not, could you add an option to downmix multichannel source files to stereo?

Cheers
manolito

LoRd_MuldeR

14th July 2011, 00:24

Can LameXP convert a 5.1 AC3 to a stereo WAV file? If so, I am too stupid to find the right setting.

If not, could you add an option to downmix multichannel source files to stereo?

Cheers
manolito

I think a 5.1 channel AC3 source will be decoded as a 5.1 channel PCM Wave. Downmix is only performed, if the selected encoder requires downmix (such as MP3).

Maybe I will add an option to allow the use to force Stereo downmix...

manolito

14th July 2011, 01:40

Maybe I will add an option to allow the use to force Stereo downmix...

That would be great....

Cheers
manolito

mecedo

18th July 2011, 15:38

I've been using version 3.11 for long time. Recently I downloaded version 4 and got disappointed. Opening from cmd-line doesn't work:( For example: LameXP.exe -add %1 to open with wav file

LoRd_MuldeR

18th July 2011, 15:50

I've been using version 3.11 for long time.

Wow, that is a really old version!

Recently I downloaded version 4 and got disappointed. Opening from cmd-line doesn't work:( For example: LameXP.exe -add %1 to open with wav file

The correct syntax is:
LameXP.exe [--add|--add-folder|--add-recursive] <path>

:)

manolito

24th July 2011, 00:13

I already posted a description of the problematic file in the Audio Encoding thread:
http://forum.doom9.org/showthread.php?p=1515371#post1515371

When I try to decode this AAC file to WAV LameXP quits with the following error message:
LameXP v4.02 (Build #578), compiled at 2011-06-14

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

*********** Ahead Software MPEG-4 AAC Decoder V2.7 ******************
Build: Apr 24 2011
Copyright 2002-2004: Ahead Software AG
http://www.audiocoding.com
Floating point version
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License.
**************************************************************************
I:\chocolat_track2_ger.aac file info:
ADTS, 6997.077 sec, 85 kbps, 48000 Hz
---------------------
| Config: 2 Ch |
---------------------
| Ch | Position |
---------------------
| 00 | Left front |
| 01 | Right front |
---------------------

PROCESS TIMEOUT !!!

Exited with code: 0xF291

A little more research revealed that LameXP uses FAAD.exe to decode AAC files. So I used FAAD manually to decode this file, and it worked flawlessly. (I actually used Tool_Faad.exe from LameXP which I salvaged from my temp folder.)

But why the timeout error? Maybe because FAAD has a bug which makes the progress indicator stop way before the end of the file is reached? For my actual file the progress indicator got stuck at 29% and stayed there. How does LameXP determine a timeout? Maybe if the progress indicator does not move for a certain amount of time?

Anyway, it would be nice if LameXP could decode my file without a timeout error. BTW I also checked a couple of older FAAD versions, but they all have the same bug...

Cheers
manolito

LoRd_MuldeR

24th July 2011, 00:29

Indeed, LameXP will kill the decoder process if it stops responding. Now the question is: Why does FAAD stop updating the progress?

Also the timeout LameXP uses is 180 seconds. Why does FAAD take more than 3 minutes to decoder that specific file? :confused:

manolito

24th July 2011, 02:35

Indeed, LameXP will kill the decoder process if it stops responding. Now the question is: Why does FAAD stop updating the progress?
I guess it is a bug in FAAD.

Also the timeout LameXP uses is 180 seconds. Why does FAAD take more than 3 minutes to decoder that specific file? :confused:
Maybe because my computer is so slow? (Celeron 1.1 GHz Coppermine)

This is the FAAD log for my AAC file:
F:\BurnerWare\Audio\AAC\Nero Digital>faad i:\de.aac
*********** Ahead Software MPEG-4 AAC Decoder V2.7 ******************

Build: Apr 24 2011
Copyright 2002-2004: Ahead Software AG
http://www.audiocoding.com
Floating point version

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License.

**************************************************************************

i:\de.aac file info:
ADTS, 6997.077 sec, 85 kbps, 48000 Hz

---------------------
| Config: 2 Ch |
---------------------
| Ch | Position |
---------------------
| 00 | Left front |
| 01 | Right front |
---------------------

Decoding i:\de.aac took: 454.77 sec. 15.39x real-time.

F:\BurnerWare\Audio\AAC\Nero Digital>

If you need to analyze the problem using this specific file, download it here:
http://www.sendspace.com/file/9jnomy

Cheers
manolito

LoRd_MuldeR

24th July 2011, 11:25

I can confirm that the FAAD status indicator gets stuck at 28% for your sample file. That's bad :rolleyes:

However it "only" took 74.35 seconds here to finish. Anyway, the only solution I see here is to further increase the timeout delay...

(There probably will be a new version up tomorrow, which will also feature "built-in" WMA support - input only, of course)

Dogway

25th July 2011, 19:55

WAVSource("source.wav")
ConvertAudioToFloat(last)
TimeStretch(tempo=136.44)
edit: Plays on MPC-HC
Checking Avisynth...
Done
Analyzing input file...
Done
Opening output file... Done
[Audio Info]
TotalSamples: 66915272
TotalSeconds: 1394
SamplesPerSec: 48000
BitsPerSample: 16
Channels: 2
AvgBytesPerSec: 192000
Dumping audio data, please wait:
AVIStreamRead succeeded, but did not return any samples!
Failed to dump audio stream (status -4). Terminating!

Exited with code: 0xFFFFFFFC

LoRd_MuldeR

25th July 2011, 21:04

Well, if AVIStreamRead() doesn't return any samples, then there's not much I can do :o :rolleyes:

It would probably be better to use the "native" Avisynth interface instead of VFW, but I currently don't have time to re-implement avs2wav...

LoRd_MuldeR

26th July 2011, 23:07

LameXP v4.03 Alpha-5:

Changes between v4.02 and v4.03:
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Updated MediaInfo to v0.7.47 (2011-07-27), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)

Also I further increased the timeout delay, until I have time to debug FAAD ;)

manolito

27th July 2011, 00:30

Also I further increased the timeout delay, until I have time to debug FAAD ;)

Cool, it works...:)
Thanks very much...

Cheers
manolito

LoRd_MuldeR

4th August 2011, 23:45

LameXP v4.03 Alpha-7:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined pattern)
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.47 (2011-07-27), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)

manolito

5th August 2011, 02:36

Thanks for the new build, everything is working fine here...:)

Meanwhile I found a workaround for the issue concerning the wav files created by Valdec (junk chunk causing problems when trying to open these files with older apps). I now use Valdec v. 0.2a which does not support wav files > 2GB and also does not use the WAVE_FORMAT_EXTENSIBLE format for multichannel wav files.

This older version is no longer available on the AC3Filter website, but the current version of Quick AVI Creator has it. Interesting find in the changelog:
- Reverted: Valdec from version 0.31b to version 0.2a
due to compatibility issues with faac.
For my needs this older version of Valdec works perfectly. Small issue with LameXP is that during decoding the progress indicator stays at 0% all the time. But the decoding goes well nevertheless (probably due to the longer timeout value).

Anyways, my wish list for LameXP has become quite short. Add the ability to downmix multichannel sources to stereo, and I will be absolutely happy...:p

Cheers
Manolito

LoRd_MuldeR

5th August 2011, 22:25

LameXP v4.03 Alpha-8:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.47 (2011-07-27), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)

manolito

6th August 2011, 19:15

* Added an option to enforce Stereo Downmix for Multi-Channel sources
This must be about the fastest response to a feature request I have ever seen, thank you very much...:)

I already spent some time testing the downmix feature, and everything works fine from the LameXP side, but sox is doing some weird things to the output. The right channel always comes out at a significantly lower volume than the left channel. It depends on the source how big this level reduction is, but it is always there.

I uploaded a 6ch AC3 where the average RMS loudness of the right channel is -13 dB compared to the left channel:
http://www.sendspace.com/file/9e8gjf

Other audio converters I tried (PX3's AC3 to WAV, BeLight, HeadAC3HE) do not show this behavior. This was my test procedure:

Select Downmix to stereo (options like Dolby Prologic 1 or 2 and Dolby Surround compatible turned off).

Normalizing, sample rate conversion all turned off.

Load the resulting wav into WaveLab and perform a Global Analysis over the whole file. Compare the Loudness Level (RMS) for both channels.

I don't know if sox allows the user to modify the downmix algorithm via command line switches, so I am not sure if you can do something about it...:rolleyes:

But again a big thanks...

Cheers
manolito

manolito

6th August 2011, 19:31

Oops, I almost forgot to ask my other question concerning Valdec.

I just noticed that you modified Valdec to support Unicode and to support decoding to STDOUT. By using the older version 2.0a I lose these features.

While I certainly can live without Unicode support, I am not sure what I am losing by not being able to decode to STDOUT. Does LameXP use this?

I tested a conversion from AC3 to AAC using the old Valdec, and everything was fine.

Cheers
manolito

LoRd_MuldeR

6th August 2011, 19:42

Hmm, that's probably a result of "wrong" channel mapping :mad:

There is a filter in SoX that allows mixing the channels with a custom channel mapping (and custom weights), I think.

But how to figure out the "correct" mapping for the individual source? That's the big question!

(BTW: The STDOUT feature I hacked into Valdec isn't used by LameXP, but the loss of Unicode support will be problematic!)

LoRd_MuldeR

6th August 2011, 20:28

Okay, it seems with the "-c" option of SoX the center channel will be mixed completely into the left channel :confused:

So I changed the Downmix option to use the "remix" filter of SoX (with explicit channel mapping) instead of the "-c" option.

I used the "Default Channel Ordering" for multiple channel WAVE files, as given on this site:
http://msdn.microsoft.com/en-us/windows/hardware/gg463006

Hopefully this will give better downmix results - as long as all decoders output Wave files with default channel ordering ;)

manolito

6th August 2011, 21:47

Sorry, the test build does not work here...:confused:

The decoding seems to work, but after this sox is not invoked at all. There is no error message, LameXP tells me that everything is fine, but I end up with an empty 2ch wav file which has a length of 44 bytes.

Cheers
manolito

LoRd_MuldeR

6th August 2011, 22:49

manolito

7th August 2011, 01:50

Here's the log file:

LameXP v4.03 (Build #625), compiled on 2011-08-06 at 21:24:07

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

E:/DOKUME~1/Achim/LOKALE~1/Temp/6f584c110cec4c36b708dbaf1de36f90/tool_valdec.exe I:\test.ac3 -w E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\9c6a9d668efc4fe78d1f38463de837f7.wav

Opening audio output PCM16 3/2.1 (5.1) 48000...
---------------------------------------
Frames/errors: 172143/0
System time: 775065ms
Process time: 576308ms
Approx. 10.46% realtime CPU usage

Exited with code: 0x0000

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

E:/DOKUME~1/Achim/LOKALE~1/Temp/6f584c110cec4c36b708dbaf1de36f90/tool_sox.exe -V3 -S --guard --temp . E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\9c6a9d668efc4fe78d1f38463de837f7.wav E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\2b50bdf89a474dfca93de87ea139c569.wav remix 1,3,4,5,7,9 2,3,4,6,8,9

E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\tool_sox.exe: SoX v14.3.2
E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\tool_sox.exe INFO formats: detected file format type `wav'
E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\tool_sox.exe INFO wav: EXTENSIBLE
Input File : 'E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\9c6a9d668efc4fe78d1f38463de837f7.wav'
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 01:31:48.16 = 264391680 samples ~ 413112 CDDA sectors
File Size : 42949672.08G
Bit Rate : 42949672.542949672.08G
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\tool_sox.exe INFO sox: Overwriting `E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\2b50bdf89a474dfca93de87ea139c569.wav'
Output File : 'E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\2b50bdf89a474dfca93de87ea139c569.wav'
Channels : 2
Sample Rate : 48000
Precision : 16-bit
Duration : 01:31:48.16 = 264391680 samples ~ 413112 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
E:\DOKUME~1\Achim\LOKALE~1\Temp\6f584c110cec4c36b708dbaf1de36f90\tool_sox.exe FAIL remix: too few input channels

Exited with code: 0x0002

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

Copy file "E:/DOKUME~1/Achim/LOKALE~1/Temp/6f584c110cec4c36b708dbaf1de36f90/2b50bdf89a474dfca93de87ea139c569.wav" to "I://test.wav"

Exited with code: 0x0000

Cheers
manolito

LoRd_MuldeR

7th August 2011, 02:51

Argh, it seems we need different parameters for each number of input channels :rolleyes:

SoX doesn't ignore no-existent channels in the remix mapping, as I had assumed. Instead it will error out, if there are too few channels.

manolito

7th August 2011, 07:17

Alright, the channel mapping of this latest test build works for me...:)

I tested it with several 5.1 AC3 files and also with a 6ch DTS file. No problems, the resulting 2ch files sounded real good, the default sox downmix algorithms seem to work well.

I could not even break it by using a 2ch AC3 source file and still have the downmix option ticked. LameXP seemed to intercept it and did not invoke sox at all.

For a while I thought that it might be a good idea to avoid sox for downmixing and use the decoder downmix capabilities instead. Valdec and Faad both have a command line switch for downmixing which would already cover AC3, DTS and AAC. No idea about the other decoders. Could be faster in many cases. But then again using sox certainly is more "universal".

Anyways, it works for me as it is right now..:cool:

Thanks again

Cheers
manolito

SeeMoreDigital

7th August 2011, 11:35

Out of interest...

Does SoX offer the ability to generate discrete multi-channel encodes from 2-channel "pro logic" encoded sources?

LoRd_MuldeR

7th August 2011, 12:29

Alright, the channel mapping of this latest test build works for me...:)

Thanks for confirming. At last a working solution.

I tested it with several 5.1 AC3 files and also with a 6ch DTS file. No problems, the resulting 2ch files sounded real good, the default sox downmix algorithms seem to work well.

If with "default sox downmix algorithm" you mean the "channels" filter (or "-c" option), then it does not work very well!

It gives an unexpected downmix result. For example, the center would be mixed into left, but not into right.

Here is a good sample to test:
http://www.mediafire.com/file/1c3oobrcnc9nkba/multichannel.wma

With the "remix" filter we can get the desired result, but only if we manually define a channel mapping for each number of input channels.

And it will only work correctly as long as the input uses "Default Channel Ordering" for multiple channel WAVE files...

I could not even break it by using a 2ch AC3 source file and still have the downmix option ticked. LameXP seemed to intercept it and did not invoke sox at all.

Yup, the Downmixing filter isn't invoked for Stereo and Mono sources.

For a while I thought that it might be a good idea to avoid sox for downmixing and use the decoder downmix capabilities instead. Valdec and Faad both have a command line switch for downmixing which would already cover AC3, DTS and AAC. No idea about the other decoders. Could be faster in many cases. But then again using sox certainly is more "universal".

Indeed I need a solution that works will arbitrary decoders. However a shortcut for decoders with "native" downmix support could be implemented.

...as it currently is done with the "resample" filter for encoders that provide "native" re-sampling support.

Does SoX offer the ability to generate discrete multi-channel encodes from 2-channel "pro logic" encoded sources?

Not that I am aware of. But shouldn't we leave "pro logic" decoding to the playback device anyway?

Doesn't make much sense to store 5.1 discrete channels with "pseudo" surround, if we can generate the same "effect" from only 2 discrete channels at playback time.

Amplifiers with more than two discrete speakers generally provide "pro logic" support. And on your computer you can use ffdshow audio decoder, for example.

LoRd_MuldeR

7th August 2011, 14:17

LameXP v4.03 Alpha-9:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.47 (2011-07-27), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)

SeeMoreDigital

7th August 2011, 15:42

LoRd_MuldeR

7th August 2011, 16:11

Bummer...

I recently re-encoded my old 1997 DVD version of Blade Runner The Directors Cut to a cropped and re-sized high bit-rate AVC video stream.

Unfortunately all the DVD releases of this movie were encoded with a 2-channel Dolby Digital Pro logic audio track.

I was hoping I could convert this 2-channel Dolby Digital Pro logic audio track to a 5.1 channel Dolby Digital discrete track at 640Kbps.

Why not decode the Digital Pro at playback time?

If you play your DVD's on a PC, you can use your favorite DShow-based player (e.g. MPC-HC) with ffdshow as audio decoder.
Ffdshow has a Dolby Pro Logic (even version "II") decoder "built-in", so you can output discrete 5.1 channels.

And, if you use a "stand alone" player, it probably is connected to a multi-channel amplifier with Pro Logic support. Isn't it?

SeeMoreDigital

7th August 2011, 16:37

Why not decode the Digital Pro at playback time?

And, if you use a "stand alone" player, it probably is connected to a multi-channel amplifier with Pro Logic support. Isn't it?I pump the bit-stream audio from my XtreamerPro hardware media player to my Onkyo surround sound amplifier via HDMI.

Although the Onkyo amplifier has many DSP modes including some THX surround sound modes, it's a case of more buttons to press... And I hate having to go through the ritual of pressing loads of buttons at the start of a movie ;)

manolito

7th August 2011, 18:43

If with "default sox downmix algorithm" you mean the "channels" filter (or "-c" option), then it does not work very well!

No, I was talking about this:
By default, where an output channel is mixed from multiple (n) input channels, each input channel
will be scaled by a factor of ¹/n. Custom mixing volumes can be set by following a given input
channel or range of input channels with a vol-spec (volume specification).
Normally I would assume that the rear channels should be mixed into the stereo file at a lower volume than the front channels. But as I said, the result sounds pretty good to me even without specifying the volume (letting sox use an even scaling factor for each channel).

BTW I cannot download the latest build from SourceForge ATM. Something is wrong with the links, it sends me into a loop.

Cheers
manolito

LoRd_MuldeR

7th August 2011, 20:31

Normally I would assume that the rear channels should be mixed into the stereo file at a lower volume than the front channels. But as I said, the result sounds pretty good to me even without specifying the volume (letting sox use an even scaling factor for each channel).

You are right. Giving the same weight to all channels probably isn't the optimal choice. Mixing the "center" input channel into the "left" and "right" output channels with the same weight as the the "right" or "left" input channels gives a bias towards "center". More correct would be 2/3 left + 1/3 center for the left channel and 2/3 right + 1/3 center for the right channel, I think. We can give that a try. Still the question is how much weight the back/side channels should get, compared to main (left/right) and center. I am open for suggestions here...

BTW I cannot download the latest build from SourceForge ATM. Something is wrong with the links, it sends me into a loop.

I can confirm. Looks like a problem at SourceForge.net. The file was uploaded hours ago, but is only available from one single mirror ("Waix") at this time.

And even that mirror doesn't seems to work, it just redirects to the "Files" page. Anyway, you can use Auto-Update for now...

manolito

7th August 2011, 21:38

Anyway, you can use Auto-Update for now...Thanks...

Luckily the correct values for different downmix scenarios have already been established...:) Tebasuna and Selur seem to be the guys to talk to.

Here is a link to a corresponding thread:
http://forum.doom9.org/showthread.php?p=1362794#post1362794

For stereo downmix this post is the one to look at:
http://forum.doom9.org/showthread.php?p=1363496#post1363496

Hope this helps...

Cheers
manolito

LoRd_MuldeR

7th August 2011, 23:02

I can't really follow these posts, but I tweaked the channels weights for the downmix filter some more:
https://github.com/lordmulder/LameXP/commit/35e80de71d00b21a427f116236f2e17307986199#src/Filter_Downmix.cpp

Basic idea: If we first create a Stereo downmix and later downmix further to Mono from there, then Center and LFE should have the same volume as Left/Right in the final mix. This means that the Center and LFE channels have to be reduced to 50% (compared to the Left/Right main channels) in the Stereo mix, because Center and LFE are mixed into both, the Left and the Right output channels. So the reduction to 50% will avoid the bias towards Center/LFE in the downmix. Moreover the Back (Surround) channels will also be reduced compared to the main channels. Sample attached.

manolito

7th August 2011, 23:31

According to Selur's post the sox remix values for stereo downmix of a 6ch source should be:

1v0.3694+3v0.2612+4v0.3694 2v0.3694+3v0.2612+5v0.3694

Note that only channels 1,3,4 are used for the left channel, 2,3,5 for the right channel.

Your channel assignment for a 6ch source is 1,3,4,5 and 2,3,4,6 which is somewhat different...:confused:

Anyways, your stereo mix sounds pretty good.

Cheers
manolito

LoRd_MuldeR

7th August 2011, 23:51

According to Selur's post the sox remix values for stereo downmix of a 6ch source should be:

1v0.3694+3v0.2612+4v0.3694 2v0.3694+3v0.2612+5v0.3694

Note that only channels 1,3,4 are used for the left channel, 2,3,5 for the right channel.

These numbers can not refer to the Default Channel Ordering (http://msdn.microsoft.com/en-us/windows/hardware/gg463006) for WAVE files!

Otherwise he would be mixing "LFE" into the Left channel only, mixing "Back Left" into the Right channel only and not using "Back Right" at all - which wouldn't make much sense ;)

Instead I assume he is mixing "Back Left" into Left, "Back Right" into Right and leaving out the LFE channel completely.

Except for the LFE and the different weights (it seems he is using the same weight for "main" and "back" plus some bias to the "center"), that is identical to my choice.

Romario

8th August 2011, 02:09

LoRd_MuldeR

8th August 2011, 02:17

Latest Beta on http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-08-07/ is BROKEN. When I click to download files, nothing happened, just redirects me on other page...please fix it or give us others links.

Please read the comment above:
http://forum.doom9.org/showpost.php?p=1518317&postcount=362

There are more reports of problems with the SourceForge file release system:
http://sourceforge.net/apps/trac/sourceforge/ticket/21078

manolito

8th August 2011, 02:17

This is old news...
I can confirm. Looks like a problem at SourceForge.net. The file was uploaded hours ago, but is only available from one single mirror ("Waix") at this time.

And even that mirror doesn't seems to work, it just redirects to the "Files" page. Anyway, you can use Auto-Update for now...

Just use Auto-Update

Cheers
manolito

//Edit
Oops. MuldeR was faster than me...

LoRd_MuldeR

8th August 2011, 12:28

Please read the comment above:
http://forum.doom9.org/showpost.php?p=1518317&postcount=362

There are more reports of problems with the SourceForge file release system:
http://sourceforge.net/apps/trac/sourceforge/ticket/21078

Seems like the problem has been fixed.

Works for me:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-08-07/LameXP.2011-08-07.Release-Static.Build-628.exe/download

LoRd_MuldeR

8th August 2011, 21:13

LameXP v4.03 Alpha-10:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.47 (2011-07-27), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)

Romario

9th August 2011, 01:25

Ok,it's work now. Thank you for your explanation.

manolito

9th August 2011, 04:16

Some more thoughts about downmixing:

http://ac3filter.net/wiki/Mixing_matrix
According to this the downmix volumes should be "normalized" to avoid clipping.

http://www.surroundassociates.com/tapeprep.html
http://www.ocularstudio.com/why-surround-better-stereo-or-quadro

According to these two links channel assignment for DTS is often different.

What do we do when downmixing DTS sources? Valdec decodes DTS in LameXP, does it reassign the channels to the "standard" assignment?

Cheers
manolito

LoRd_MuldeR

9th August 2011, 11:41

Some more thoughts about downmixing:

http://ac3filter.net/wiki/Mixing_matrix
According to this the downmix volumes should be "normalized" to avoid clipping.

That's what SoX does by default. When mixing together n channels, the volume of each channel is reduced to 1/n.

So in sum the volume cannot exceed 1.0, which prevents clipping.

When using "custom" weights you have to take care that the sum of all weights (per channel) is 1.0 or below. Otherwise clipping is possible.

Of course I tried to choose weights that exactly match 1.0 in sum ;)

According to these two links channel assignment for DTS is often different.

What do we do when downmixing DTS sources? Valdec decodes DTS in LameXP, does it reassign the channels to the "standard" assignment?

Well, when implementing a "downmix" filter some channel mapping has to be assume.

As said before, LameXP now assumes the "Default Channel Ordering" for multiple channel WAVE files.

I think any decoder which outputs WAVE files is supposed to use that channel mapping...

(In theory different channel mappings could be used/assumed, depending on the individual input format or decoder of the current file.
But at the moment the "dowmix" filter doesn't know about input formats. And, in a well-designed system, it shouldn't have to!)

LoRd_MuldeR

15th August 2011, 22:15

LameXP v4.03 Alpha-12:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this thread for details) and removed all remnants of "old" decoder
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.47 (2011-07-27), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 (this is experimental!)

Seems like I finally figured out a feasible way to make Visual Studio 2010 binaries run on Windows 2000:
http://mulder.googlecode.com/svn/trunk/Utils/EncodePointerLib/README.txt

(And yes, I am well aware that the EncodeDecodePointer substitute function does not provide the extra "protection" of the original implementation)

LoRd_MuldeR

19th August 2011, 15:55

LameXP v4.03 Alpha-13:

This version adds experimental support for the FHG AAC Encoder that is included with latest Winamp.
You will need the Add-in to enable the FHG AAC Encoder in LameXP. See the included instructions!

manolito

19th August 2011, 22:07

Just out of curiosity:
Do you think that the FHG AAC encoder has an edge over Nero?
(HydrogenAudio is conducting a listening test, but no results so far...)

Cheers
manolito

LoRd_MuldeR

19th August 2011, 22:15

Just out of curiosity:
Do you think that the FHG AAC encoder has an edge over Nero?

I will leave that decision up to the users. Haven't done any comprehensive tests yet.

LoRd_MuldeR

21st August 2011, 14:54

LameXP v4.03 Alpha-14:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder (see the FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for install instructions!)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.48 (2011-08-17), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 (this is experimental!)

Brazil2

22nd August 2011, 11:21

LameXP v4.03 Alpha-14:
* Added optional support for the FHG AAC Encoder (see the FAQ doc for install instructions!)
You may want to check this wrapper which is only 18KB, compared to the 398KB of the one you link to, and source code is included:
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=89518&view=findpost&p=763079

And in your FAQ (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) you provide a direct link to a version of Winamp which is the German only version. You may want to link either to the English version (http://download.nullsoft.com/winamp/client/winamp5621_full_emusic-7plus_en-us.exe) and/or to the international version (http://download.nullsoft.com/winamp/client/winamp5621_full_emusic-7plus_all.exe) which includes German, Dutch, French, Italian, Polish, Russian, Spanish, Swedish, Korean, Japanese, Chinese, Turkish, Portuguese and Romanian languages.

Just my two cents :)

LoRd_MuldeR

22nd August 2011, 12:08

You may want to check this wrapper which is only 18KB, compared to the 398KB of the one you link to, and source code is included:
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=89518&view=findpost&p=763079

That's exactly the one I use ;)

(As you may have noticed, I linked 'libsndfile' in a static way in order to get rid of another DLL dependency, which explains the different size of the EXE file)

And in your FAQ (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) you provide a direct link to a version of Winamp which is the German only version. You may want to link either to the English version (http://download.nullsoft.com/winamp/client/winamp5621_full_emusic-7plus_en-us.exe) and/or to the international version (http://download.nullsoft.com/winamp/client/winamp5621_full_emusic-7plus_all.exe) which includes German, Dutch, French, Italian, Polish, Russian, Spanish, Swedish, Korean, Japanese, Chinese, Turkish, Portuguese and Romanian languages.

You are right. I will change the link to point to the 'international' version.

b66pak

22nd August 2011, 18:55

LoRd_MuldeR

22nd August 2011, 19:01

hi, by any chance did you modify the sources to add support for stdout? (for adts CBR)?
_

I don't know if output to 'stdout' is possible with their encoder API :confused:

Output as MP4 probably requires random access to the output file, which isn't possible when writing to stdout. ADTS might work though (in theory).

Also I think the CBR limitation of ADTS mode is a limitation of the encoder library, not of the CLI front-end...

nik33134

24th August 2011, 14:21

Hi I have an old Athlon 64 3200+ running WinXP 32bit, and find the old version of LameXP (LameXP v3.18 Hotfix-2 Build 88) to be twice as fast when encoding 320kb constant bitrate mp3s, vs the 4.02 build 578. My only complaint is that the old version keeps bugging me that the code is more than a year old and I have to update (by the way, the check for updates is disabled). If I choose cancel, the program closes, and if I choose "yes", it goes online and checks for updates. Please tell me there's a way to disable this, because it's driving me nuts. I want to stick with the old version. Thanks

LoRd_MuldeR

24th August 2011, 19:51

Hello, nik33134.

Hi I have an old Athlon 64 3200+ running WinXP 32bit, and find the old version of LameXP (LameXP v3.18 Hotfix-2 Build 88) to be twice as fast when encoding 320kb constant bitrate mp3s, vs the 4.02 build 578.

That's a quite surprising result :eek:

My only complaint is that the old version keeps bugging me that the code is more than a year old and I have to update (by the way, the check for updates is disabled). If I choose cancel, the program closes, and if I choose "yes", it goes online and checks for updates.

It's intentional. Most users simply refuse to update and stick with archaic versions. So we need to help them a bit ;)

Please tell me there's a way to disable this, because it's driving me nuts.

Not without compiling your own "custom" build from the sources :o

I want to stick with the old version. Thanks

The old 3.xx is version has been deprecated and it's highly recommended to update to 4.xx now!

There are just too many nasty restrictions in the old version (no support of Unicode file names or tags !!!) and the audio tools that were used in the old version are outdated too.

So would you please run the following benchmark on your system and post the results, then we might be able to find out what is going wrong:
http://www.mediafire.com/file/ct5yk2144j5wixn/benchmark.2011-08-24.rar

(This includes the LAME build that was used in LameXP v3.18 Hotfix-2 Build 88, the build that is used in the current version as well as another build for comparison).

Here are my results:
vendor_id : GenuineIntel
cpu family : 6
model : 15
stepping : 7
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm nx lm lahf_lm
cpu MHz : 2398.008
model name : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz

[VBR MODE]
lame-3.98.4-GEN.exe 8 2.113739 0.006455 D:\SVN\Tools\LAME\benchmark\\bin\lame-3.98.4-GEN.exe -h -V2 --nohist D:\SVN\Tools\LAME\benchmark\\etc\Input.wav NUL
lame-3.99.0-ICC.exe 8 2.151387 0.012290 D:\SVN\Tools\LAME\benchmark\\bin\lame-3.99.0-ICC.exe -h -V2 --nohist D:\SVN\Tools\LAME\benchmark\\etc\Input.wav NUL
lame-3.99.0-MSC.exe 8 2.318193 0.011178 D:\SVN\Tools\LAME\benchmark\\bin\lame-3.99.0-MSC.exe -h -V2 --nohist D:\SVN\Tools\LAME\benchmark\\etc\Input.wav NUL

[CBR MODE]
lame-3.98.4-GEN.exe 8 3.770149 0.076191 D:\SVN\Tools\LAME\benchmark\\bin\lame-3.98.4-GEN.exe -h --cbr -b 320 --nohist D:\SVN\Tools\LAME\benchmark\\etc\Input.wav NUL
lame-3.99.0-ICC.exe 8 3.257647 0.038184 D:\SVN\Tools\LAME\benchmark\\bin\lame-3.99.0-ICC.exe -h --cbr -b 320 --nohist D:\SVN\Tools\LAME\benchmark\\etc\Input.wav NUL
lame-3.99.0-MSC.exe 8 3.556128 0.003099 D:\SVN\Tools\LAME\benchmark\\bin\lame-3.99.0-MSC.exe -h --cbr -b 320 --nohist D:\SVN\Tools\LAME\benchmark\\etc\Input.wav NUL
Concision for my system:
The "old" build was slightly faster in VBR mode and significant slower in CBR mode, compared to the "up-to-date" build.

b66pak

24th August 2011, 20:24

Here are my results:
vendor_id : AuthenticAMD
cpu family : 15
model : 47
stepping : 2
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 pni syscall nx mmxext fxsr_opt lm 3dnowext 3dnow lahf_lm
cpu MHz : 2380.318
model name : AMD Athlon(tm) 64 Processor 3800+

[VBR MODE]
lame-3.98.4-GEN.exe 8 2.653358 0.005877 F:\benchmark.2011-08-24\\bin\lame-3.98.4-GEN.exe -h -V2 --nohist F:\benchmark.2011-08-24\\etc\Input.wav NUL
lame-3.99.0-ICC.exe 8 2.942623 0.006475 F:\benchmark.2011-08-24\\bin\lame-3.99.0-ICC.exe -h -V2 --nohist F:\benchmark.2011-08-24\\etc\Input.wav NUL
lame-3.99.0-MSC.exe 8 3.315548 0.007737 F:\benchmark.2011-08-24\\bin\lame-3.99.0-MSC.exe -h -V2 --nohist F:\benchmark.2011-08-24\\etc\Input.wav NUL

[CBR MODE]
lame-3.98.4-GEN.exe 8 5.171427 0.012839 F:\benchmark.2011-08-24\\bin\lame-3.98.4-GEN.exe -h --cbr -b 320 --nohist F:\benchmark.2011-08-24\\etc\Input.wav NUL
lame-3.99.0-ICC.exe 8 4.843703 0.006763 F:\benchmark.2011-08-24\\bin\lame-3.99.0-ICC.exe -h --cbr -b 320 --nohist F:\benchmark.2011-08-24\\etc\Input.wav NUL
lame-3.99.0-MSC.exe 8 5.425726 0.004313 F:\benchmark.2011-08-24\\bin\lame-3.99.0-MSC.exe -h --cbr -b 320 --nohist F:\benchmark.2011-08-24\\etc\Input.wav NUL

Wed 08/24/2011 - 22:23:11.17
_

LoRd_MuldeR

24th August 2011, 20:31

b66pak, interesting results. Even though you have an AMD processor, the ICL build (as used in current LameXP) still is significant faster than the MSVC build.

Also your results confirm that the "old" build was a bit faster in VBR mode (although the difference is bigger than on my system) and slower in CBR mode, compared to the "up-to-date" build.

However this doesn't explain what nik33134 is reporting. He claims that the "old" build was faster in CBR mode. And he uses a very similar CPU :confused:

nik33134

24th August 2011, 23:08

So here are the results I got:

vendor_id : AuthenticAMD
cpu family : 15
model : 47
stepping : 0
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 pni syscall nx mmxext fxsr_opt lm 3dnowext 3dnow lahf_lm
cpu MHz : 1995.039
model name : AMD Athlon(tm) 64 Processor 3200+

[VBR MODE]
lame-3.98.4-GEN.exe 8 3.203830 0.031366 "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\bin\lame-3.98.4-GEN.exe" -h -V2 --nohist "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\etc\Input.wav" NUL
lame-3.99.0-ICC.exe 8 3.548249 0.112188 "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\bin\lame-3.99.0-ICC.exe" -h -V2 --nohist "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\etc\Input.wav" NUL
lame-3.99.0-MSC.exe 8 4.010275 0.228478 "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\bin\lame-3.99.0-MSC.exe" -h -V2 --nohist "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\etc\Input.wav" NUL

[CBR MODE]
lame-3.98.4-GEN.exe 8 6.203974 0.026840 "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\bin\lame-3.98.4-GEN.exe" -h --cbr -b 320 --nohist "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\etc\Input.wav" NUL
lame-3.99.0-ICC.exe 8 5.810394 0.007591 "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\bin\lame-3.99.0-ICC.exe" -h --cbr -b 320 --nohist "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\etc\Input.wav" NUL
lame-3.99.0-MSC.exe 8 6.503573 0.004490 "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\bin\lame-3.99.0-MSC.exe" -h --cbr -b 320 --nohist "C:\Documents and Settings\n\Desktop\benchmark.2011-08-24\\etc\Input.wav" NUL

Thu 08/25/2011 - 1:00:20.28

LoRd_MuldeR

24th August 2011, 23:22

This shows that the "new" version encodes a bit slower (but certainly not two times!) in VBR mode and encodes quite a bit faster in CBR mode, compared to the "old" version.

I can't see how this matches your previous report :confused:

How exactly did you measure the speed of LameXP v4.03 against v3.18 on your system before? And are you absolutely sure that you got the latest build of LameXP v4.03 (build #664 at this moment) ???

Also: Is your processor single or dual core? And how many encoder instances are you running in parallel? How is the CPU usage - encoder process(es) -vs- LameXP main process - while encoding?

nik33134

24th August 2011, 23:53

LoRd_MuldeR

25th August 2011, 00:04

Ok, I just encoded a 7:26 flac to mp3 with the old version (constant bitrate 320, max quality, at 44100Hz, auto select channel mode) and the encoding took 1:12:34. Then I used the new version 4.02 build 578 (320 CBR, best quality, 44100Hz, auto select), and got 2:18:36. The new version created an mp3 of 17,886,730 bytes, and the old version a 17,858,745 bytes mp3 file.

Is this the time for encoding only or including the decoding of the input file? BTW: What is the format of the input file?

Oh, and can you please update to the latest v4.03 build? Enable "Tools" -> "Configuration" -> "Check for Beta Updates" and then check for updates!

I have a single core and use only one instance at a time. My observations have been empirical, and this is the first time that I used a stopwatch while encoding. But it's always been like this for me when I compared with the eye (how fast he percentage numbers change). Now either the benchmark does not fit the situation, or I don't know what...

Well, the benchmark compares the encoder binary used by LameXP v4.03 against the one that was used v3.18.

And your results clearly show that the difference in pure encoding speed is rather small. Also it shows that the "new" version encodes even faster in CBR mode.

There are still two scenarios I can think of:
(a) The encoding parameters are different between v4.03 and v3.18 in some way. If slower/faster settings were used, this would explain the difference.
(b) The LameXP v4.03 front-end process uses significantly more CPU time than v3.18 on your system and this way slows down the encoder process.

Can you please check both things with the help of ProcessExplorer (http://technet.microsoft.com/en-us/sysinternals/bb896653) ???

nik33134

25th August 2011, 00:29

My original file is a FLAC, and the times that I state are only the encoding time, without the initial decoding time. I have not updated to the latest beta yet. I just run another test with the same file with ABR 192kbps. Results are 2:06:43 with the new stable version, and 1:16:54 with the old version. I will try to use the process explorer and see if I can see anything. My XP has 2 Gigs of memory and is pretty slimmed down (few services, and no unnecessary programs running, only Avira and firefox).

LoRd_MuldeR

25th August 2011, 00:33

My original file is a FLAC, and the times that I state are only the encoding time, without the initial decoding time. I have not updated to the latest beta yet.

Can you please update to the latest build now?

I just run another test with the same file with ABR 192kbps. Results are 2:06:43 with the new stable version, and 1:16:54 with the old version. I will try to use the process explorer and see if I can see anything. My XP has 2 Gigs of memory and is pretty slimmed down (few services, and no unnecessary programs running, only Avira and firefox).

Please check the CPU usage of "LameXP.exe" (front-end process) and "lame.exe" (encoder process) in ProcessExplorer while encoding. Do that for version 3.18 as well as for version 4.03.

Also in the properties of the "lame.exe" process check the "command line" field - again for both versions. If there is a difference in the command-line arguments, it may explain the difference.

nik33134

25th August 2011, 00:58

Ok, I updated to the latest beta. I run process explorer and got CPU usage at 98.44% to 100% for both the old, and the new versions (ool_lame.exe and ool_lameenc.exe). The lameXP.exe showed no CPU usage at all in either version. In the new version I had a console running that displayed "This OS doesn't support ItaskbarList3 interface".

The times for the encode this time were 1:12:39 for the old version, and 2:17:79 for the new beta, for the same 52.7MB Flac file.

LoRd_MuldeR

25th August 2011, 01:08

Ok, I updated to the latest beta. I run process explorer and got CPU usage at 98.44% to 100% for both the old, and the new versions (ool_lame.exe and ool_lameenc.exe). The lameXP.exe showed no CPU usage at all in either version.

Good. So 'LameXP.exe' eating too much CPU time is not the problem :)

In the new version I had a console running that displayed "This OS doesn't support ItaskbarList3 interface".

That message is normal on pre-Win7 systems. Nothing to worry about.

(The debug console is shown for all Beta versions)

The times for the encode this time were 1:12:39 for the old version, and 2:17:79 for the new beta, for the same 52.7MB Flac file.

Did you check the "Command line" for 'tool_lame(enc).exe' for both versions? You find it by right-click and Properties in the ProcessExplorer.

nik33134

25th August 2011, 01:23

LoRd_MuldeR

25th August 2011, 01:42

Yes, the parameter for the new version is:
tool_lame.exe --nohist -q 0 --cbr -b 320 --resample 44100 --tt "Theme from 'Antarctica'" --ta Vangelis --tl "The Best Of Instrumental Works" --tg Instrumental --tc "Encoded with LameXP" --ty 2008 --tn 1 --ti

For the old version, it's:
tool_lameenc.exe" --nohist -q 0 -b 320 --resample 44.1 --add-id3v2 --tt "Theme from 'Antarctica'" --ta "Vangelis" --tl "The Best Of Instrumental Works" --ty 2008 --tc "Encoded with LameXP" --tn 1 --tg "Instrumental"

So you are using ultra slow placebo encoder settings and then you complain about speed? :devil:

I can re-produce that the "new" version indeed is noticeably slower than the "old" version when using these ultra slow placebo settings!

Of course both versions are SLOW with such settings. So try to use something more sane, like "-q 2", which is equivalent to "-h".

(It is the "LAME Algorithm Quality" slider that you want to adjust)

Is the 100% CPU usage normal?

Yes, normal and desirable ;)

CPU usage is the percentage of time that your CPU is working, i.e. not sleeping (waiting for I/O).

When encoding, you want your CPU to sleep as few as possible, right? ^^

nik33134

25th August 2011, 01:54

I see now. But how do I set the q to not be zero. Is it from the "Advanced Options" menu, the Lame Algorithm Quality? I've always set it to "best" in the past, should I set it to high quality instead? Anyways, thank you for your help.

LoRd_MuldeR

25th August 2011, 02:02

I see now. But how do I set the q to not be zero. Is it from the "Advanced Options" menu, the Lame Algorithm Quality?

Exactly :)

I've always set it to "best" in the past, should I set it to high quality instead?

Well, tweaking an encoder for "speed -vs- quality" always is a trade-off.

So if you want to squish out more quality at the same bitrate, then you have to accept a slower encoding speed. That's live.

However there always is a point where using even slower settings only gives a very minor additional improvement (if at all) for a significant additional speed cost.

Obviously you would only use such "placebo" settings, if you don't care about speed at all ;)

The LAME manual says:

-q 0: use slowest & best possible version of all algorithms. -q 0 and -q 1 are slow and may not produce higher quality.
-q 2: recommended. Same as -h.
-q 5: default value. Good speed, reasonable quality.
-q 7: same as -f. Very fast, ok quality.

Anyways, thank you for your help.

No problem.

LoRd_MuldeR

27th August 2011, 19:46

LameXP v4.03 Beta-1:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-08-27/

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.48 (2011-08-17), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

manolito

30th August 2011, 00:02

After the HydrogenAudio listening test determined that fhgaac was superior to Nero AAC I decided to do some tests:

1. Speed is pretty much the same. FHGAAC is a tad slower than Nero (17 min vs. 16 min), but this is hardly significant.

2. Since FHG does not support ABR (and CBR is not really desirable), quality mode looks like the optimal mode to do a comparison. But this is not so easy:

Nero has a quality scale from 0.00 to 1.00. FHG uses VBR presets in the range of 1 to 5. LameXP only has a slider for the Nero style quality settings, so it somehow maps the Nero settings to the FHG settings.

In my first test I used a quality setting of 0.30 (which roughly corresponds to an average bitrate of 96 kbp/s). For Nero I got a file size of 67.2 MB, for FHG the file was much smaller (49.1 MB). The 0.30 quality setting was mapped to FHG VBR 2.

The next encode with FHG was done with a quality setting of 0.40 which corresponded to a FHG setting of VBR 3. This time the file size was almost identical to the encode done with Nero using a quality setting of 0.30.

I do not have the means to test the quality of the encoded files, my audio hardware is just too shabby. All encoded files sounded pretty much identical to me. But it looks like the mapping of the Nero quality settings to the FHG settings is not perfect yet.

Another hint:
If you want to use the FHG encoder but you do not care for WinAmp, you can extract the necessary files from the installer executable without actually installing WinAmp. Download the WinAmp installer, open it with 7zip and extract the required files.

Cheers
manolito

LoRd_MuldeR

30th August 2011, 00:55

Nero has a quality scale from 0.00 to 1.00. FHG uses VBR presets in the range of 1 to 5. LameXP only has a slider for the Nero style quality settings, so it somehow maps the Nero settings to the FHG settings. But it looks like the mapping of the Nero quality settings to the FHG settings is not perfect yet.

I am using a mapping that will map 0.00 to 1 and 1.00 to 5. The values between 0.00 and 1.00 are mapped to values between 1 and 5 in a linear fashion.

As the quality parameter of the FHG encoder only accepts integers, the values have to be rounded. That makes the mapping kind of coarse-grained...

If you want to use the FHG encoder but you do not care for WinAmp, you can extract the necessary files from the installer executable without actually installing WinAmp. Download the WinAmp installer, open it with 7zip and extract the required files.

I know. But I don't think it would be very "fair" to tell people to extract the encoder plugin without actually installing Winamp ;)

manolito

30th August 2011, 23:23

While testing the fhgaac encoder I stumbled upon a severe bug which probably has been there for quite a while:

After converting a 6-ch AC3 to a 6-ch AAC I noticed that the volume of the encoded file was way lower than the volume of the original AC3. Then I did the same encode using Nero, but the volume was still way too low. So I figured that this was a AAC issue, and I thought I might get better results using LameXP's normalize feature.

But it turned out that this approach did not work at all. SoX seemed to do its thing normally, but afterwards the encode stopped immediately. No matter if Nero or FHG was chosen as the encoder. Looks like the SoX output is not usable for ther AAC encoders. Here is the log:
LameXP v4.03 (Build #676), compiled on 2011-08-27 at 16:14:23

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

E:/DOKUME~1/Achim/LOKALE~1/Temp/1ca6b065a50346d48d45cb45e7cb39e8/tool_valdec.exe I:\test.ac3 -w I:\\bc36e19738db4fdf932efd5a9a240637.wav

Opening audio output PCM16 3/2.1 (5.1) 48000...
---------------------------------------
Frames/errors: 166277/0
System time: 766202ms
Process time: 582247ms
Approx. 10.94% realtime CPU usage

Exited with code: 0x0000

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

E:/DOKUME~1/Achim/LOKALE~1/Temp/1ca6b065a50346d48d45cb45e7cb39e8/tool_sox.exe -V3 -S --temp . I:\\bc36e19738db4fdf932efd5a9a240637.wav I:\\6b54e1c909f1409da8eab7f2ef915619.wav gain -n -0.50

E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe: SoX v14.3.2
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO formats: detected file format type `wav'
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO wav: EXTENSIBLE
Input File : 'I:\\bc36e19738db4fdf932efd5a9a240637.wav'
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 01:28:40.45 = 255381504 samples ~ 399034 CDDA sectors
File Size : 42949672.19G
Bit Rate : 42949672.842949672.19G
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO sox: Overwriting `I:\\6b54e1c909f1409da8eab7f2ef915619.wav'
Output File : 'I:\\6b54e1c909f1409da8eab7f2ef915619.wav'
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 01:28:40.45 = 255381504 samples ~ 399034 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO sox: effects chain: input 48000Hz 6 channels
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO sox: effects chain: gain 48000Hz 6 channels
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO sox: effects chain: dither 48000Hz 6 channels
E:\DOKUME~1\Achim\LOKALE~1\Temp\1ca6b065a50346d48d45cb45e7cb39e8\tool_sox.exe INFO sox: effects chain: output 48000Hz 6 channels
Done.

Exited with code: 0x0000

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

E:/Programme/LameXP/fhgaacenc.exe --vbr 3 --dll E:/Programme/LameXP/enc_fhgaac.dll I:\\6b54e1c909f1409da8eab7f2ef915619.wav I:\\test.mp4

fhgaacenc version 20110822 by tmkk
E:\Programme\LameXP\enc_fhgaac.dll

Exited with code: 0x0000

The log does not indicate any problems, but the resulting AAC file had a length of 64 ms. Using the Nero AAC encoder made no difference, so I tend to assume that SoX cannot normalize multichannel WAV files. What do you think?

Cheers
manolito

mike20021969

30th August 2011, 23:37

Another hint:
If you want to use the FHG encoder but you do not care for WinAmp, you can extract the necessary files from the installer executable without actually installing WinAmp. Download the WinAmp installer, open it with 7zip and extract the required files.

I download Winamp from winamp.com. I extracted all the files with 7Zip, I couldn't find anything with an FHG reference. The were lots of folders and dll's. What is the file name to search/look for?

LoRd_MuldeR

30th August 2011, 23:48

I download Winamp from winamp.com. I extracted all the files with 7Zip, I couldn't find anything with an FHG reference. The were lots of folders and dll's. What is the file name to search/look for?

Please follow the instructions included with the 'FHG AAC Encoder Add-in' package:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0

@manolito
The reason why the audio converted from the AC-3 source appears to have a lower volume is because AC-3 has much bigger dynamic range.
Also I can confirm that there is a problem with the normalization filter. It's not only the AAC encoder. The same issue occurs with OggEnc, for example.
I will have to investigate what is going wrong here. But I will be away for the next few days, so please be patient...

Motenai Yoda

3rd September 2011, 22:37

err.. adding concentric folders still don't work?

LoRd_MuldeR

4th September 2011, 22:52

Am I supposed to know what a "concentric" folder is? :confused:

manolito

4th September 2011, 23:40

RE normalization filter:

This has nothing to do with the decoder or encoder which LameXP uses. It is solely a SoX issue. And the problem was already present in V. 4.02 final.

For a test just try to convert a 6ch WAV (does not matter if it is in the Extensible Format or not) to a normalized 6ch WAV. Fails...

Cheers
manolito

LoRd_MuldeR

4th September 2011, 23:42

Motenai Yoda

5th September 2011, 02:12

Am I supposed to know what a "concentric" folder is? :confused:

in a simple way "one inside another" but I think "recursive" can best be understood by a dev.

ie
a folder "Micky Maus"
a folder "Goofy" into "Micky Maus"
an mp3 into "Goofy"

re normalization filter
there is an WaveGain(S) too
This is a special version of WaveGain that is designed to be used to apply ReplayGain to
a number of mono wave files that comprise the individual channels within a multi-channel
audio stream. For example, the 6 mono wave files that would comprise a 5.1 audio stream.

Processing regards the mono wave files as an album, but applies the gain that was computed
for the single loudest track to all of the tracks, There is a command line option, '-m',
that will cause the program to pause following the analysis phase to allow the user to
enter a dB adjustment that will be added to the value computed by the ReplayGain algorithm.
It is the user's responsibility to ensure that clipping will not result from the value
entered.

You may find other uses for this version. Input is not limited to mono files, but the style of processing will necessarily limit where it may be appropriate to use this.

edit: when "save output files to the same location where the input file is located" but "prepend relative source file path to output file" is still checked (even if greyed), it works right?

LoRd_MuldeR

5th September 2011, 02:55

in a simple way "one inside another" but I think "recursive" can best be understood by a dev.

There is an option to add a folder in a recursive way. So what exactly is the problem?

(Seems to work as expected for me)

when "save output files to the same location where the input file is located" but "prepend relative source file path to output file" is still checked (even if greyed), it works right?

The "prepend relative source file path to output file" option does not apply, if "save output files to the same location where the input file is located" is enabled.

Motenai Yoda

5th September 2011, 13:46

1- ok but I would expect it was the default method for drag'n'drop
2- look http://www.youtube.com/watch?v=MwyXFIObdug

LoRd_MuldeR

5th September 2011, 14:09

ok but I would expect it was the default method for drag'n'drop

Nope, when folders are added via drag&drop it is not done in a recursive way by default.

It's implemented that way, because adding a folder recursively might add a HUGE number files which can take a very long time.

Maybe the default behavior can be changed in a way that will trigger "recursive" mode when a folder that only contains sub-folders (but no files) is dropped.

(I want to avoid adding yet another option for this)

manolito

5th September 2011, 15:13

:scared:

Can this be reproduced with the "official" SoX binaries for Win32?

Unfortunately yes...:eek:

I tried with the current version of SoX (14.3.2), but it behaves exactly the same as the built-in version.

Cheers
manolito

LoRd_MuldeR

5th September 2011, 15:26

Thx for the info. At least it's not a build issue then ;)

b66pak

5th September 2011, 18:13

also broken with 14.3.1 or 14.3.0...
_

LoRd_MuldeR

5th September 2011, 22:32

manolito

5th September 2011, 23:39

Yes, this fixes it...:thanks:

It adds a little to the encoding time, but I could not break it using all kinds of multichannel input files.

I still find it hard to explain why omitting the -e or -b option causes SoX to completely screw up the conversion. Strange...:confused:

Anyway, it works now, thanks again.

Cheers
manolito

b66pak

6th September 2011, 20:30

This evening I did some more tests: SoX' gain filter doesn't fail with all multi-channel sources. And it only fails on some when the "-n" option is used :confused:

Anyway, if I also add the "-e" or "-b" option that seems to fix the issue. At least for my samples that failed before. Consequently LameXP will now use "-ne" instead of "-n" only.

Hopefully it works with your sample too. A new build is available via auto-update...

this have to be a temporary solution! because -ne is not even close to -n...

-ne will rise the loudness of the central channel if its peak is lower than the side channels or will rise the loudness of the side channels if its peaks is lower than the central channel...

in other words the some level of DRC will be applied...
_

LoRd_MuldeR

6th September 2011, 21:04

this have to be a temporary solution!

As I am not a SoX developer, this is not in my hands, unfortunately.

(And nope, I'm not currently planning to add yet another tool to LameXP for normalization)

because -ne is not even close to -n...

-ne will rise the loudness of the central channel if its peak is lower than the side channels or will rise the loudness of the side channels if its peaks is lower than the central channel...

I am aware that "-ne" works slightly different.

Anyway, generally I would assume that all channels had been recorded at the same levels. And if not, that's probably unintentionally.

So their peaks should be at the same volume too!

A channel would only be "amplified" more than the others, if there is not a single peak in that channel for the whole duration of the audio...

in other words the some level of DRC will be applied...

Might be applied.

manolito

7th September 2011, 00:23

Just a thought:
Have you tried to use norm instead of gain -n?

Cheers
manolito

LoRd_MuldeR

7th September 2011, 00:56

The global "--norm" option basically is a shortcut for inserting the "gain -n" filter. Also the "norm" filter is nothing but an alias for "gain −n".

And yes, I tried it, just to be sure. But same effect ;)

LoRd_MuldeR

17th September 2011, 20:51

LameXP v4.03 Beta-2:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-09-17/

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.49 (2011-09-09), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a problem with the "normalization" filter that sometimes caused the resulting file to be empty
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

Build #687 reverted NSIS to v2.46.1, because NSIS v2.46.2 broke Win2k support. Apart from that, build #687 is identical to build build #686.

b66pak

18th September 2011, 17:56

here (https://neon1.net/prog/normalizer.html) is the source code under GNU General Public License for a very fast normalizer...it has support only for 8/16bit simple header wavs up to 4gb...
_

LoRd_MuldeR

19th September 2011, 21:30

LameXP running on Windows 8:
http://img841.imageshack.us/img841/2341/lamexpwin8.jpg

Unfortunately it seems that some of the tools, including MediaInfo, will crash right away on Windows 8. Bummer! :(

Seems like only the 64-Bit tools will crash. And yes, I'm using the x64 edition of Win8.

It appears that MPRESS causes the issue. The original 64-Bit binary works fine, while the MPRESS-compressed one crashes right away.

As a temporary workaround you can use "--force-cpu-no-64bit" with the latest build in order to make LameXP work on Win8 64-Bit.

MajorX

21st September 2011, 04:59

Nice GUI. :)
Is LameXP support audio encoding from video file like*.mkv or *.avi ? If not is it possible to add it in LameXP ?

LoRd_MuldeR

21st September 2011, 11:10

Nice GUI. :)
Is LameXP support audio encoding from video file like*.mkv or *.avi?

Nope. But Avisynth-input (audio only) is supported. So you can encode the audio from your video files that way...

Use a simple script, such as:
FFAudioSource("C:\Some Path\Input.mkv")

If not is it possible to add it in LameXP ?

Possible, maybe. We would need to integrate a tool that can split the video file and "extract" the audio stream (e.g. MKVExtract for MKV files) for further processing.

But this additional "splitting" step it doesn't fit into the current design of the software. So this would require bigger changes in the code...

LoRd_MuldeR

29th September 2011, 22:13

LameXP v4.03 Beta-3:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Updated Qt runtime libraries to v4.8.0 Beta-1 (2011-07-19), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.49 (2011-09-09), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a problem with the "normalization" filter that sometimes caused the resulting file to be empty
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

manolito

4th October 2011, 01:07

Just noticed an unnecessary annoyance with the SoX "-ne" parameter. Whenever this parameter is used, SoX switches to 2-pass mode which of course doubles the filtering time.

While this is probably unavoidable for multichannel sources, it is complete nonsense to do 2 passes for stereo sources. SoX by itself is not smart enough to switch from "-ne" to just "-n" and does 2 passes on stereo sources which is a big waste of time.

Could you add some code to LameXP to use "-ne" conditionally only if the source has more than 2 channels?

Cheers
manolito

LoRd_MuldeR

4th October 2011, 01:17

Well, all the reason why we switched from "-n" to "-ne" is because "-n" is buggy. So, unfortunately, I think we can not switch back (now).

(Also, to my understanding, normalization always requires two passes. That's because the maximum peak in the file needs to be determined first, before the actual processing can start. Normalizing only within a local window would effectively "compress" the dynamics. IMHO that's not "normalization" any more)

manolito

4th October 2011, 14:35

Well, all the reason why we switched from "-n" to "-ne" is because "-n" is buggy. So, unfortunately, I think we can not switch back (now).
Did you ever encounter any problems with the "-n" parameter for stereo files? I certainly didn't.

(Also, to my understanding, normalization always requires two passes. That's because the maximum peak in the file needs to be determined first, before the actual processing can start. Normalizing only within a local window would effectively "compress" the dynamics. IMHO that's not "normalization" any more)
Alright, point taken, but then the "-ne" paramter invokes a third pass...:)
How else would you explain the performance hit when using "-ne" compared to just "-n" for stereo sources? I just did a couple of tests, and the results are reproduceable.

Source: 2-ch WAV 1.4 GB
Convert 2-ch WAV to normalized 2-ch WAV
Commandline: SoX.exe infile outfile gain -n(e) -0.50

Execution time for "-ne": 16min 20sec
Execution time for "-n": 12min 40sec

To make things worse, the resulting normalized files are NOT identical (which they should be).

So I would still lobby for using "-ne" only for multichannel sources...:p

Cheers
manolito

LoRd_MuldeR

4th October 2011, 14:46

Did you ever encounter any problems with the "-n" parameter for stereo files? I certainly didn't

I did not encounter any problems with "-n" and Stereo files either. But that's probably just by chance :confused:

To make things worse, the resulting normalized files are NOT identical (which they should be).

Well, "-ne" works slightly different from "-n". As far as I understood:

The latter will normalize all samples in all channels by the same factor, thus it is limited by the loudest sample in the loudest channel.

At the same time the former will normalize all samples in a channel by the the same factor, but may choose a different factor for each channel.

Consequently it is expected to get different results with "-ne", iff the peak values differ between your channels...

manolito

4th October 2011, 16:39

At the same time the former will normalize all samples in a channel by the the same factor, but may choose a different factor for each channel.

From the SoX manual:
Given the −e option, the levels of the audio channels of a multi-channel file are ‘equalised’, i.e.
gain is applied to all channels other than that with the highest peak level, such that all channels
attain the same peak level

The question is if the SoX guys regard a stereo file as "multi-channel". If they do then the "-ne" parameter will inevitably change the stereo balance of the source which is REAL BAD. Makes it unusable for stereo files.

Maybe the "-nb" option would be more suitable for stereo sources because it uses RMS values instead of peaks. This will result in a file with an even stereo balance (both channels have the same RMS value). This is often quite desirable, but probably not always...

Cheers
manolito

LoRd_MuldeR

4th October 2011, 16:48

If they do then the "-ne" parameter will inevitably change the stereo balance of the source which is REAL BAD. Makes it unusable for stereo files.

It would do so, if the Stereo channels have different peak levels.

And I think, except for very rare cases, the peak levels of the channels of a Stereo recording should be identical (and should be equalized, if they differ).

b66pak

4th October 2011, 17:27

no they are not...from my experience it is always a 0.5 to 1 db between left and right channels...

for 5.1 is even worse: center vs left+right front is 3-4 db and center vs left+right side/back is 4-8db...
_

manolito

4th October 2011, 17:35

And I think, except for very rare cases, the peak levels of the channels of a Stereo recording should be identical (and should be equalized, if they differ).
This is not true at all (maybe for classical recordings). Most modern instruments (i.e. synthesizers, electric guitar and bass, percussion) generate high peaks which do not contribute to the perceived loudness of the track. Unless brutal compression or brickwall limiting is used to achieve maximum loudness, the peak levels for the 2 channels will amost never be identical while the acoustic balance is perfect.

I have a background as a recording engineer (many years ago in the good old analog times), but if you do not believe me, test it for yourself:

Take some of your favorite audio records (good quality please, maybe jazz), load them into WaveLab and do a "Global Analysis". This will give you the peak levels plus the RMS levels for each track (separately for each channel).

Cheers
manolito

LoRd_MuldeR

4th October 2011, 18:15

Yes, I know that "sample value" and "perceived loudness" aren't the same at all and that RMS is a better loudness indicator. And I would never suggest to use the sample value to judge the loudness of a track. But we are not talking about average values here. Not even about average values for small segments. It's all about peak (maximum) values for complete tracks. Sure there are "high peaks which do not contribute to the perceived loudness of the track". And the number of such peaks may be very different between the channels. But each track/channel contains millions of individual sample values. So usually there is at least one (and one is sufficient for maximum calculation) of these "high" peaks in each channel. Actually my finding is that the maximum sample value generally is identical (or pretty close) between both channels of a Stereo recording, while both, the average and especially the maximum, RMS can differ significantly between the channels...

Example:
http://img834.imageshack.us/img834/3149/maxpeakvalue.png

b66pak

4th October 2011, 19:26

its time for some examples...

stereo (normalized after downmixing from 5.1)

[20:43:30.796] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n remix -m 1v0.3694,3v0.2612,5v0.3694 2v0.3694,3v0.2612,6v0.3694 gain -n stats

[20:48:21.750] Overall Left Right

[20:48:21.750] DC offset -0.000005 -0.000005 -0.000005
[20:48:21.750] Min level -0.934752 -0.934752 -0.776695
[20:48:21.750] Max level 1.000000 1.000000 0.872530

[20:48:21.750] Pk lev dB 0.00 0.00 -1.18

[20:48:21.750] RMS lev dB -26.14 -26.14 -26.15
[20:48:21.750] RMS Pk dB -10.96 -11.04 -10.96
[20:48:21.750] RMS Tr dB -1.#J -1.#J -1.#J
[20:48:21.750] Crest factor - 20.28 17.70
[20:48:21.750] Flat factor 0.00 0.00 0.00
[20:48:21.750] Pk count 2 2 2
[20:48:21.750] Bit-depth 32/32 32/32 32/32
[20:48:21.750] Num samples 124M
[20:48:21.750] Length s 2582.272
[20:48:21.750] Scale max 1.000000
[20:48:21.750] Window s 0.050
[20:48:21.765] Process terminated with code: 0
[20:48:21.765] Execution took 4 minute(s), 50 second(s).

[20:48:22.406] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n remix -m 1v0.3694,3v0.2612,5v0.3694 2v0.3694,3v0.2612,6v0.3694 gain -n stats

[20:51:12.343] Overall Left Right

[20:51:12.343] DC offset -0.000002 -0.000001 -0.000002
[20:51:12.343] Min level -1.000000 -1.000000 -0.930617
[20:51:12.343] Max level 0.958940 0.958940 0.937415

[20:51:12.343] Pk lev dB 0.00 0.00 -0.56

[20:51:12.343] RMS lev dB -25.23 -25.23 -25.23
[20:51:12.343] RMS Pk dB -9.66 -10.45 -9.66
[20:51:12.343] RMS Tr dB -1.#J -1.#J -1.#J
[20:51:12.343] Crest factor - 18.27 17.11
[20:51:12.343] Flat factor 0.00 0.00 0.00
[20:51:12.343] Pk count 2 2 2
[20:51:12.343] Bit-depth 32/32 32/32 32/32
[20:51:12.343] Num samples 126M
[20:51:12.343] Length s 2631.840
[20:51:12.343] Scale max 1.000000
[20:51:12.343] Window s 0.050
[20:51:12.343] Process terminated with code: 0
[20:51:12.343] Execution took 2 minute(s), 49 second(s).

[20:51:12.953] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n remix -m 1v0.3694,3v0.2612,5v0.3694 2v0.3694,3v0.2612,6v0.3694 gain -n stats

[20:55:57.062] Overall Left Right

[20:55:57.062] DC offset -0.000003 -0.000002 -0.000003
[20:55:57.062] Min level -0.966295 -0.940450 -0.966295
[20:55:57.062] Max level 1.000000 0.951579 1.000000

[20:55:57.062] Pk lev dB 0.00 -0.43 0.00

[20:55:57.062] RMS lev dB -24.49 -24.46 -24.52
[20:55:57.062] RMS Pk dB -8.03 -8.33 -8.03
[20:55:57.062] RMS Tr dB -133.10 -132.31 -133.10
[20:55:57.062] Crest factor - 15.90 16.82
[20:55:57.062] Flat factor 0.00 0.00 0.00
[20:55:57.062] Pk count 2 2 2
[20:55:57.062] Bit-depth 32/32 32/32 32/32
[20:55:57.062] Num samples 125M
[20:55:57.062] Length s 2595.808
[20:55:57.062] Scale max 1.000000
[20:55:57.062] Window s 0.050
[20:55:57.093] Process terminated with code: 0
[20:55:57.093] Execution took 4 minute(s), 43 second(s).

[20:55:57.640] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n remix -m 1v0.3694,3v0.2612,5v0.3694 2v0.3694,3v0.2612,6v0.3694 gain -n stats

[20:58:52.781] Overall Left Right

[20:58:52.781] DC offset -0.000003 -0.000002 -0.000003
[20:58:52.781] Min level -0.983251 -0.983251 -0.936560
[20:58:52.781] Max level 1.000000 1.000000 0.970447

[20:58:52.781] Pk lev dB 0.00 0.00 -0.26

[20:58:52.781] RMS lev dB -27.89 -27.96 -27.82
[20:58:52.781] RMS Pk dB -10.44 -10.44 -11.09
[20:58:52.781] RMS Tr dB -98.63 -98.63 -98.42
[20:58:52.781] Crest factor - 24.99 23.88
[20:58:52.781] Flat factor 0.00 0.00 0.00
[20:58:52.781] Pk count 2 2 2
[20:58:52.781] Bit-depth 32/32 32/32 32/32
[20:58:52.781] Num samples 124M
[20:58:52.781] Length s 2593.312
[20:58:52.781] Scale max 1.000000
[20:58:52.781] Window s 0.050
[20:58:52.781] Process terminated with code: 0
[20:58:52.781] Execution took 2 minute(s), 54 second(s).

original 5.1

[20:59:52.140] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n stats

[21:01:40.687] Overall Ch1 Ch2 Ch3 Ch4 Ch5 Ch6

[21:01:40.687] DC offset -0.000003 -0.000002 -0.000002 -0.000003 -0.000001 -0.000001 -0.000000
[21:01:40.687] Min level -0.464905 -0.464905 -0.443695 -0.464386 -0.321808 -0.427521 -0.333832
[21:01:40.687] Max level 0.501587 0.464935 0.481415 0.501587 0.349060 0.424225 0.382660

[21:01:40.687] Pk lev dB -5.99 -6.65 -6.35 -5.99 -9.14 -7.38 -8.34

0.00 -0.66 -0.36 0.00 -3.15 -1.39 -2.35 < this will be after normalizing

[21:01:40.687] RMS lev dB -32.58 -31.85 -31.59 -27.83 -39.44 -39.40 -40.73
[21:01:40.687] RMS Pk dB -12.62 -12.83 -12.62 -15.78 -14.06 -13.20 -19.63
[21:01:40.687] RMS Tr dB -1.#J -1.#J -1.#J -1.#J -1.#J -1.#J -1.#J
[21:01:40.687] Crest factor - 18.19 18.28 12.35 32.72 39.88 41.64
[21:01:40.687] Flat factor 12.84 0.00 0.00 0.00 17.08 4.44 0.00
[21:01:40.687] Pk count 4.33 2 3 2 14 3 2
[21:01:40.687] Bit-depth 15/16 15/16 15/16 15/16 15/16 15/16 15/16
[21:01:40.687] Num samples 124M
[21:01:40.687] Length s 2582.272
[21:01:40.687] Scale max 1.000000
[21:01:40.687] Window s 0.050
[21:01:40.687] Process terminated with code: 0
[21:01:40.687] Execution took 1 minute(s), 48 second(s).

[21:01:40.781] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n stats

[21:03:28.468] Overall Ch1 Ch2 Ch3 Ch4 Ch5 Ch6

[21:03:28.468] DC offset -0.000001 0.000000 -0.000001 -0.000000 -0.000000 -0.000000 -0.000000
[21:03:28.468] Min level -0.608521 -0.398529 -0.406006 -0.608521 -0.022552 -0.063690 -0.074982
[21:03:28.468] Max level 0.667389 0.328278 0.462891 0.667389 0.016663 0.068573 0.065765

[21:03:28.468] Pk lev dB -3.51 -7.99 -6.69 -3.51 -32.94 -23.28 -22.50

0.00 -4.48 -3.18 0.00 -29.43 -19.77 -18.99 < this will be after normalizing

[21:03:28.468] RMS lev dB -35.90 -38.52 -38.33 -29.07 -65.58 -51.39 -51.07
[21:03:28.468] RMS Pk dB -15.47 -16.51 -15.71 -15.47 -39.79 -31.00 -30.26
[21:03:28.468] RMS Tr dB -1.#J -1.#J -1.#J -1.#J -1.#J -1.#J -1.#J
[21:03:28.468] Crest factor - 33.62 38.19 18.97 42.86 25.45 26.83
[21:03:28.468] Flat factor 18.42 0.00 0.00 0.00 21.23 0.00 0.00
[21:03:28.468] Pk count 5.50 2 2 2 23 2 2
[21:03:28.468] Bit-depth 16/16 15/16 15/16 16/16 11/16 13/16 13/16
[21:03:28.468] Num samples 126M
[21:03:28.468] Length s 2631.840
[21:03:28.468] Scale max 1.000000
[21:03:28.468] Window s 0.050
[21:03:28.468] Process terminated with code: 0
[21:03:28.468] Execution took 1 minute(s), 47 second(s).

[21:03:28.937] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n stats

[21:05:14.234] Overall Ch1 Ch2 Ch3 Ch4 Ch5 Ch6

[21:05:14.234] DC offset -0.000001 -0.000000 -0.000001 -0.000000 -0.000000 -0.000001 -0.000001
[21:05:14.234] Min level -0.805939 -0.367798 -0.404785 -0.805939 -0.203033 -0.312012 -0.278168
[21:05:14.234] Max level 0.834442 0.398376 0.410004 0.834442 0.189209 0.278931 0.304901

[21:05:14.250] Pk lev dB -1.57 -7.99 -7.74 -1.57 -13.85 -10.12 -10.32

0.00 -6.42 -6.17 0.00 -12.28 -8.55 -8.75 < this will be after normalizing

[21:05:14.250] RMS lev dB -34.19 -34.00 -34.26 -28.99 -54.86 -39.13 -38.95
[21:05:14.250] RMS Pk dB -15.26 -15.62 -15.26 -15.52 -20.48 -22.44 -22.31
[21:05:14.250] RMS Tr dB -1.#J -138.72 -139.84 -147.72 -1.#J -1.#J -1.#J
[21:05:14.250] Crest factor - 19.96 21.16 23.49 112.39 28.22 27.01
[21:05:14.250] Flat factor 7.76 0.00 0.00 0.00 12.57 0.00 0.00
[21:05:14.250] Pk count 3 2 2 2 8 2 2
[21:05:14.250] Bit-depth 16/16 15/16 15/16 16/16 14/16 15/16 15/16
[21:05:14.250] Num samples 125M
[21:05:14.250] Length s 2595.808
[21:05:14.250] Scale max 1.000000
[21:05:14.250] Window s 0.050
[21:05:14.250] Process terminated with code: 0
[21:05:14.250] Execution took 1 minute(s), 45 second(s).

[21:05:14.359] Commandline: sox -V0 -t raw -L -s -b 16 -c 6 -r 48000 - -n stats

[21:06:50.937] Overall Ch1 Ch2 Ch3 Ch4 Ch5 Ch6

[21:06:50.937] DC offset -0.000002 -0.000001 -0.000002 -0.000001 -0.000000 -0.000000 -0.000000
[21:06:50.937] Min level -0.676056 -0.536987 -0.549896 -0.676056 -0.183105 -0.209625 -0.200348
[21:06:50.937] Max level 0.750793 0.552826 0.549530 0.750793 0.181732 0.236572 0.201385

[21:06:50.937] Pk lev dB -2.49 -5.15 -5.19 -2.49 -14.75 -12.52 -13.92

0.00 -2.66 -2.70 0.00 -12.26 -10.03 -11.43 < this will be after normalizing

[21:06:50.937] RMS lev dB -34.29 -33.64 -33.28 -29.03 -53.29 -44.20 -44.04
[21:06:50.937] RMS Pk dB -12.28 -12.28 -12.86 -14.12 -22.45 -24.03 -23.55
[21:06:50.937] RMS Tr dB -1.#J -107.22 -105.87 -128.05 -1.#J -193.53 -192.30
[21:06:50.937] Crest factor - 26.59 25.36 21.24 84.59 38.39 32.05
[21:06:50.937] Flat factor 0.00 0.00 0.00 0.00 0.00 0.00 0.00
[21:06:50.937] Pk count 2 2 2 2 2 2 2
[21:06:50.937] Bit-depth 16/16 16/16 16/16 16/16 14/16 14/16 14/16
[21:06:50.937] Num samples 124M
[21:06:50.937] Length s 2593.312
[21:06:50.937] Scale max 1.000000
[21:06:50.937] Window s 0.050
[21:06:50.937] Process terminated with code: 0
[21:06:50.937] Execution took 1 minute(s), 36 second(s).

-ne for stereo will do:

0.00 -1.18 > 0.00 0.00 > meaning the right channel will be amplified by 1.18bd

0.00 -0.56 > 0.00 0.00 > meaning the right channel will be amplified by 0.56bd

-0.43 0.00 > 0.00 0.00 > meaning the left channel will be amplified by 0.43bd

0.00 -0.26 > 0.00 0.00 > meaning the right channel will be amplified by 0.26bd

-ne for original 5.1 will do:

-0.66 -0.36 0.00 -3.15 -1.39 -2.35 > 0.00 0.00 0.00 0.00 0.00 0.00 > meaning the music (left/right channels) and the surround effect (side left/right channels) will be amplified a lot!

-4.48 -3.18 0.00 -29.43 -19.77 -18.99 > 0.00 0.00 0.00 0.00 0.00 0.00 > meaning the music (left/right channels) and the surround effect (side left/right channels) will be amplified a lot!

-6.42 -6.17 0.00 -12.28 -8.55 -8.75 > 0.00 0.00 0.00 0.00 0.00 0.00 > meaning the music (left/right channels) and the surround effect (side left/right channels) will be amplified a lot!

-2.66 -2.70 0.00 -12.26 -10.03 -11.43 > 0.00 0.00 0.00 0.00 0.00 0.00 > meaning the music (left/right channels) and the surround effect (side left/right channels) will be amplified a lot!
_

LoRd_MuldeR

6th October 2011, 23:31

After all I have decided to make the "channel equalization mode" an option.

Now you can even select "-n" again, but it will still fail with (some) multi-channel files, of course.

The new build is available via auto-update...

manolito

7th October 2011, 00:31

Thanks very much...

Could you elaborate on how the three different normalization modes (max level, max energy, none) translate to SoX parameters? Couldn't find anything in the documentation...

Cheers
manolito

LoRd_MuldeR

7th October 2011, 00:34

Could you elaborate on how the three different normalization modes translate to SoX parameters?

"Peak Level" == "-ne", "RMS Level" == "-nb", "None" == "-n"

b66pak

7th October 2011, 01:23

thanks a lot...
_

CaMoTblku_OnToM

10th October 2011, 12:50

ugly visual bug in latest stable release http://www.youtube.com/watch?v=_aYfZjy0YFs
how i can turn off this useless visual effects?
i think previous interface in 3.18 was much better

LoRd_MuldeR

10th October 2011, 13:47

ugly visual bug in latest stable release http://www.youtube.com/watch?v=_aYfZjy0YFs

Hello. That's not a bug or "effect". Some translations simply use much longer strings than the original (English) texts.

So, if necessary, the window width will be increased step-by-step, until all strings fit in...

(And nope, I can't increase the initial window width. This would only mislead the translators to use even longer strings ^^)

But feel free to suggest a better/shorter translation. Translation fixes always are welcome!

i think previous interface in 3.18 was much better

The "old" interface was built with Delphi 7.0 and didn't even support Unicode characters :p

The "new" Qt-based interface is MUCH advanced...

LoRd_MuldeR

14th October 2011, 20:45

LameXP v4.03 Beta-4:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Added Polish translation, thanks to Sir Daniel K <sir.daniel.k@gmail.com>
* Updated Qt runtime libraries to v4.8.0 RC-1 (2011-10-13), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.13.4 (2011-09-07), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.50 (2011-09-23), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a problem with the "normalization" filter that sometimes caused the resulting file to be empty
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

LoRd_MuldeR

16th October 2011, 19:39

LameXP v4.03 Beta-5:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Added Polish translation, thanks to Sir Daniel K <sir.daniel.k@gmail.com>
* Added channel equalization options to the normalization filter (also fixes multi-channel processing)
* Updated Qt runtime libraries to v4.8.0 RC-1 (2011-10-13), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.13.4 (2011-09-07), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.50 (2011-09-23), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

Warning: There was a serious bug (http://img546.imageshack.us/img546/857/wupdatebug.png) in Beta-4 which prevents the Web Update utility from working properly :o
If you already have Beta-4 installed on your computer, then Auto Update won't work and you have to download/install the new version manually this time!
Sorry for any inconvenience...

Dogway

17th October 2011, 20:35

Do you happen to know if the aac or mp3 encoder dithers the output when input is for example 32 bit float wav? I didn't see anything related in the neroaacend cli help

LoRd_MuldeR

17th October 2011, 20:42

Do you happen to know if the aac or mp3 encoder dithers the output when input is for example 32 bit float wav? I didn't see anything related in the neroaacend cli help

Well, I think, whether the output will be (dithered) integer or floating-point depends on the decoder, which you use to play the compressed bitstream later.

There was a lengthy discussion on whether audio decoders should output floating-point here:
http://forum.doom9.org/showthread.php?t=156966

Dogway

17th October 2011, 20:46

wav decoder...Im reading here (http://www.gearslutz.com/board/so-much-gear-so-little-time/105258-aac-24-bit-uncompressed-files.html) and here (http://www.audiobanter.com/archive/index.php/t-39170.html) and it seems the encoders just don't care and "truncate" the signal. Maybe you could add dithering in the wav decoder?
Reading a bit more it seems they could probably dither, but doing it or not is not a critical issue.... : /

LoRd_MuldeR

17th October 2011, 20:53

I'm not exactly sure what you mean with "wav decoder", because (uncompressed) Wave files don't need any decoder.

And how are the MP3 or AAC encoders related to decoding :confused:

Dogway

17th October 2011, 21:16

sorry I didn't think mp3 or aac used already 32bit fp.

mike20021969

18th October 2011, 17:06

Using 4.03 beta 5, am I correct in saying the the debug console not be disabled? It would appear it cannot.
(This is the first time I installed a LameXP beta version).

Also, is there a new stable version around the corner? :)

LoRd_MuldeR

18th October 2011, 17:31

Using 4.03 beta 5, am I correct in saying the the debug console not be disabled? It would appear it cannot.
(This is the first time I installed a LameXP beta version).

Please read the F.A.Q. document:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#900a2a6c

Also, is there a new stable version around the corner? :)

Yes, soon. It will contain the LAME 3.99 final release.

mike20021969

18th October 2011, 17:38

Please read the F.A.Q. document:
Thanks for pointing me to that :)
Yes, soon. It will contain the LAME 3.99 final release.
Excellent.
:thanks:

LoRd_MuldeR

18th October 2011, 19:23

LameXP v4.03 Beta-6:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Added Polish translation, thanks to Sir Daniel K <sir.daniel.k@gmail.com>
* Added channel equalization options to the normalization filter (also fixes multi-channel processing)
* Updated Qt runtime libraries to v4.8.0 RC-1 (2011-10-13), compiled with MSVC 10.0
* Updated LAME encoder to v3.99 Final (2011-10-17), compiled with ICL 12.1.6 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.131))
* Updated mpg123 decoder to v1.13.4 (2011-09-07), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.50 (2011-09-23), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed a potential bug in CPU type detection that might have caused the wrong binary to be used
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

LoRd_MuldeR

23rd October 2011, 18:36

LameXP v4.03 RC-1:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Added an option to hibernate the computer (aka "Suspend-to-Disk") instead of shutting it down
* Added Polish translation, thanks to Sir Daniel K <sir.daniel.k@gmail.com>
* Added channel equalization options to the normalization filter (also fixes multi-channel processing)
* Updated Qt runtime libraries to v4.8.0 RC-1 (2011-10-13), compiled with MSVC 10.0
* Updated LAME encoder to v3.99 Final (2011-10-17), compiled with ICL 12.1.6 and MSVC 10.0 (details)
* Updated mpg123 decoder to v1.13.4 (2011-09-07), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.50 (2011-09-23), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed a potential bug in CPU type detection that might have caused the wrong binary to be used
* Fixed Cue Sheet import for tracks with certain characters in the title
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

Motenai Yoda

23rd October 2011, 21:22

LoRd_MuldeR

23rd October 2011, 21:57

it has the same bug that I've previously reported:
if "Prepend relative source file path to output file" in "Output Directory" tab is checked, it still remains active (but greyed) even when "Save output files to the same location where the input file is located" is checked.

I think I already had commented on that one. But again: If the "Save output files to the same location where the input file is located" is checked, then the "Prepend relative source file path to output file" option doesn't make much sense. And therefore it is disabled (greyed out). So what exactly, in your opinion, is the problem here? :confused:

-feature request
to avoid intense (and slow) hd activity, as the size of an intermediate raw files can be easily calculated previously (duration_in_seconds * frequency * bitdepth * channels), it should be possible, if the free RAM size is greater than the above + an offset, use a ram file for the raw intermediate.

Not possible. That's because LameXP is "only" a GUI front-end to a bunch of command-line tools. These tools read their input from a file and they also write their output back to a file. When LameXP calls one of the command-line tools (e.g. an encoder or a decoder), then it can tell the tool which file to read the input from and also which file to write the output to. But that's it! You can't tell the tool to keep the output in the memory (RAM). And even if you could, each process still has its own (virtual) memory space! That means: If, for example, the decoder process would keep the output in a buffer inside its memory (instead of writing it to a file), then the output data would be gone for good, as soon as the decoder process terminates - with no way for the encoder process to every access that data.

Well, that's not the whole truth. It is possible to pass data from one process to another one directly in the memory - by using a pipe. Or more specifically: By having the first process write the data to STDOUT and having the second process read the data from STDIN. But this has other problems: For example, the second process can not determine the size of the input until it has read/processed everything, because seeking is not possible when reading from a pipe. Also not all tools used in LameXP do support reading/writing from/to STDOUT/STDIN. Last but not least, implementing the usage of pipes (at least for the tools that do support it) would require fundamental changes in the architecture of LameXP. For example, decoding and encoding would then happen in parallel, rather than doing it in two separate steps...

Anyway, what you can do already: Create a "RAM Disk" and move LameXP's Temp directory to that RAM Disk.

Motenai Yoda

23rd October 2011, 23:06

I think I already had commented on that one. But again: If the "Save output files to the same location where the input file is located" is checked, then the "Prepend relative source file path to output file" option doesn't make much sense. And therefore it is disabled (greyed out). So what exactly, in your opinion, is the problem here? :confused:

when "Save output files to the same location where the input file is located" and "Prepend relative source file path to output file" are checked (although the latter is grayed),
if u process a file in
"C:\lord_mulder\work"

the output file is placed in
"C:\lord_mulder\work\lord_mulder\work"

I've posted a video at the time. http://forum.doom9.org/showthread.php?p=1523849#post1523849

imho or is grayed/disabled/unapplied or is active/applied.

Not possible. That's because LameXP is "only" a GUI front-end to a bunch of command-line tools. These tools read their input from a file and they also write their output back to a file. When LameXP calls one of the command-line tools (e.g. an encoder or a decoder), then it can tell the tool which file to read the input from and also which file to write the output to. But that's it! You can't tell the tool to keep the output in the memory (RAM). And even if you could, each process still has its own (virtual) memory space! That means: If, for example, the decoder process would keep the output in a buffer inside its memory (instead of writing it to a file), then the output data would be gone for good, as soon as the decoder process terminates - with no way for the encoder process to every access that data.

Well, that's not the whole truth. It is possible to pass data from one process to another one directly in the memory - by using a pipe. Or more specifically: By having the first process write the data to STDOUT and having the second process read the data from STDIN. But this has other problems: For example, the second process can not determine the size of the input until it has read/processed everything, because seeking is not possible when reading from a pipe. Also not all tools used in LameXP do support reading/writing from/to STDOUT/STDIN. Last but not least, implementing the usage of pipes (at least for the tools that do support it) would require fundamental changes in the architecture of LameXP. For example, decoding and encoding would then happen in parallel, rather than doing it in two separate steps...

Anyway, what you can do already: Create a "RAM Disk" and move LameXP's Temp directory to that RAM Disk.

yeah, I thought that there were such problems

LoRd_MuldeR

23rd October 2011, 23:13

when "Save output files to the same location where the input file is located" and "Prepend relative source file path to output file" are checked (although the latter is grayed),
if u process a file in
"C:\lord_mulder\work"

the output file is placed in
"C:\lord_mulder\work\lord_mulder\work"

I've posted a video at the time.

imho or is grayed or is active/applied.

Oh, I see :eek:

Sorry, I did not get your point before. But the example made it clear now.

Thank you for the report, I will fix this ASAP.

LoRd_MuldeR

24th October 2011, 01:40

LameXP v4.03 RC-2:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Added an option to hibernate the computer (aka "Suspend-to-Disk") instead of shutting it down
* Added Polish translation, thanks to Sir Daniel K <sir.daniel.k@gmail.com>
* Added channel equalization options to the normalization filter (also fixes multi-channel processing)
* Updated Qt runtime libraries to v4.8.0 RC-1 (2011-10-13), compiled with MSVC 10.0
* Updated LAME encoder to v3.99 Final (2011-10-17), compiled with ICL 12.1.6 and MSVC 10.0 (details)
* Updated mpg123 decoder to v1.13.4 (2011-09-07), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.50 (2011-09-23), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed a potential bug in CPU type detection that might have caused the wrong binary to be used
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a bug with "Prepend relative source file path to output file" under certain conditions
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

LoRd_MuldeR

29th October 2011, 23:38

LameXP v4.03 RC-3:

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Added an option to hibernate the computer (aka "Suspend-to-Disk") instead of shutting it down
* Added Polish translation, thanks to Sir Daniel K <sir.daniel.k@gmail.com>
* Added channel equalization options to the normalization filter (also fixes multi-channel processing)
* Added indicators for current CPU usage, RAM usage and free diskspace to the processing window
* Updated Qt runtime libraries to v4.8.0 RC-1 (2011-10-13), compiled with MSVC 10.0
* Updated LAME encoder to v3.99 Final (2011-10-17), compiled with ICL 12.1.6 and MSVC 10.0 (details)
* Updated mpg123 decoder to v1.13.4 (2011-09-07), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.50 (2011-09-23), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed a potential bug in CPU type detection that might have caused the wrong binary to be used
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a bug with "Prepend relative source file path to output file" under certain conditions
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

If nobody has any objections, this will go final very soon :)

mike20021969

29th October 2011, 23:59

LoRd_MuldeR

30th October 2011, 00:08

Thanks for the update...roll on the Final :)

I like using AAC encoding - it's just a shame that my iPod and Sony mp3 players don't "support the sound quality" of the lower bitrates (e.g. 32kbps or 64kbps) - they sound rather crisp on the computer, but the high-end is lacking on the mp3 players (it's similar to listening to mp3pro encodes on a software player which doesn't support mp3pro playback).

That sounds like your player doesn't support HE-AAC:

HE-AAC is nothing but (LC-)AAC combined with SBR (Spectral Band Replication), the same way "mp3PRO" is just good old MP3 with SBR pre-/postprocessing.

Any player that supports LC-AAC can decode HE-AAC as well. But without a fully HE-capable decoder you only get half the sample rate for 'HE' files (e.g. 22.05 Hz instead of 44.1 Hz).

As a result the "higher" frequencies are missing completely when playing HE-AAC files with a LC-AAC player/decoder, giving it a rather "dull" sound...

(Note: HE-AAC is only used for ultra-low bitrates, which explains why you won't get those problems at higher bitrates. At higher bitrates plain LC-AAC will be used)

mike20021969

30th October 2011, 10:39

Thanks for that very clear explanation :)
Hopefully, there's a branded mp3 player "out there" that supports HE-AAC.

SeeMoreDigital

30th October 2011, 13:24

Thanks for that very clear explanation :)
Hopefully, there's a branded mp3 player "out there" that supports HE-AAC.
Given QuickTime7 player now supports AAC-HE. How about all you iPod owners getting together and campaigning Apple to support it?

Plus, you could also remind them there's such a thing as AAC-HE PS too!

Przemek_Sperling

30th October 2011, 16:52

Thanks for that very clear explanation :)
Hopefully, there's a branded mp3 player "out there" that supports HE-AAC.

Pity that your player does not work with RockBox http://www.rockbox.org
I have to say that the firmware is great.

SeeMoreDigital

30th October 2011, 23:08

Pity that your player does not work with RockBox http://www.rockbox.org
I have to say that the firmware is great.Many (non Apple) cell phones fully support playback of AAC-LC and AAC-HE sources.

All my Mediatek chip-set based hardware players fully support playback of AAC-LC, AAC-HE and AAC-HE PS sources ;)

LoRd_MuldeR

31st October 2011, 16:38

LameXP v4.03 has been released :)

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Added an option to hibernate the computer (aka "Suspend-to-Disk") instead of shutting it down
* Added Polish translation, thanks to Sir Daniel K <sir.daniel.k@gmail.com>
* Added channel equalization options to the normalization filter (also fixes multi-channel processing)
* Added indicators for current CPU usage, RAM usage and free diskspace to the processing window
* Updated Qt runtime libraries to v4.8.0 RC-1 (2011-10-13), compiled with MSVC 10.0
* Updated LAME encoder to v3.99 Final (2011-10-17), compiled with ICL 12.1.6 and MSVC 10.0 (details)
* Updated mpg123 decoder to v1.13.4 (2011-09-07), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.50 (2011-09-23), compiled with MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed a potential bug in CPU type detection that might have caused the wrong binary to be used
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a bug with "Prepend relative source file path to output file" under certain conditions
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

mike20021969

31st October 2011, 20:42

LameXP v4.03 has been released :)
Nice one.
:thanks:

Next beta tomorrow? ;)

SeeMoreDigital

31st October 2011, 20:45

LameXP v4.03 has been released :)
Excellent...

MajorX

1st November 2011, 03:16

Thanks LoRd_MuldeR :)
I have few questions plzz help,

I want to compress heavily an audio(with 32kbps, 6 channel to 2 channel) .....so Is it good to enable volume normalization if yes what setting should i use now the defaults value are
Peak Volume(dB)= -0.50
Equalization Mode= Peak Level

Can i hide dropBox?

LoRd_MuldeR

1st November 2011, 10:11

I want to compress heavily an audio(with 32kbps, 6 channel to 2 channel) .....

I'd recommend to use AAC for that purpose.

so Is it good to enable volume normalization if yes what setting should i use now the defaults value are
Peak Volume(dB)= -0.50
Equalization Mode= Peak Level

I don't think volume normalizations makes the audio easier/harder to compress, so it shouldn't matter.

WARNING: People tend to rate the quality of audio higher when it's "louder". So be sure that you don't get fooled here :)

Consequently, if you want to test the effect of normalization, you should compare the following:

(1) Compress -> Normalize -> Decompress/Listen
(2) Normalize -> Compress -> Decompress/Listen

Can i hide dropBox?

Sure. Right-click.

MadRat

2nd November 2011, 05:02

I'm... really sorry to bring this up but... Norton is blocking tool_lame.exe as having highly suspicious behavior and telling me I should restart my computer.

mariush

2nd November 2011, 07:11

Uninstall or update Norton then, because it's stupid and incorrect determination from Norton. tool_lame.exe is a mp3 encoder - it takes an uncompressed audio file and creates a mp3 file.

Othniel Graichen

2nd November 2011, 17:04

Othniel Graichen

2nd November 2011, 18:50

I have more information about my previous report.

Windows Explorer is stupid. ok you knew that already.

Well Final-1 Build does include artwork.

Mp3tag shows it, MPC can play my VBR mp3s. But WMP
will not handle my VBR mp3 files and Windows Explorer will
not show the embedded artwork.

I was not aware of how frail and wimpy WMP is as I
primarily use MPC. Please excuse the false alarm.
I hope to make it up to you in working on the Linux
release of LameXP.

LoRd_MuldeR

2nd November 2011, 20:59

I'm... really sorry to bring this up but... Norton is blocking tool_lame.exe as having highly suspicious behavior and telling me I should restart my computer.

As always in this situation: Please re-scan the suspicious file at http://www.virustotal.com/ to be sure it isn't really infected.

Then report the FALSE POSITIVE to the developer of your AntiVirus software. And, if they don't fix the problem, switch to a better product.

(I can't do anything about the issue, because it is impossible to know what aspect of LAME triggers the failure in their software)

LoRd_MuldeR

2nd November 2011, 21:09

I am testing LameXp v4.03 Final-1 Build 764 this AM.

Today I processed some mp3 files containing cover art into a new directory with this build. I lost the cover art in the new
folder

I am reencoding with LAME -- the input files are 48k CBR mp3, and the output is VBR 9 at 16k sampling frequency. The encoding went ok, but the cover art is now gone.

Your release notes say this is supposed to work. This is issue #1.

LameXP will detect/extract "cover art" that is embedded in your MP3 files. And, if the selected encoder supports it, then it will re-embed the cover art.

However LameXP will not deal with cover art that is saved as a separate JPEG file or in any other way.

Please use Mp3Tag (http://www.mp3tag.de/en/) to make sure your input MP3 files contain cover art. Then, after the files have been re-encoded, check the output files again.

Also I was unable to select 8 as my minimum bitrate in LAME having instead to supply -b 8 using the Lame cmdline options.
Is there a reason for that or is this an oversight?

The values were limited to a "sane" range. Why do you want to force LAME to use such ultra-low bitrates? :scared:

Note: The lowest supported bitrate in original MP3 (as defined by MPEG-1) is 32 kbps. MPEG-2 added even lower bitrates to MP3, but only for 16, 22.05 and 24 kHz!

See also:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/switchs.html#b

Furthermore, when I attempted to drop my audiobooks folder on LameXP's main window, it said 1 file not recognized. I had to enter that directory and select all its subfolders to drag and drop. The source was a folder on my Desktop. So when I processed, all files were created in a flat output folder losing the original directory structure.

That's probably because there actually was an un-supported file in the folder your dropped onto LameXP ;)

I guess there was something like "thumbs.db" or "desktop.ini" in your folder. Maybe you didn't see the file, because it was hidden. LameXP will reject those, of course.

(I should make LameXP ignore files like "thumbs.db" or "desktop.ini" in a future version though)

Now when I select "prepend directory structure" it
creates users/owner/Desktop/NWT.cbr/subfolders/files within
the output folder which is better than having them altogether but I guess I do not know how to control where the files are generated. This is the least important issue as I can always prune the folder and rename at a higher level.
I'm not sure if this is an issue or I just dont know how it is supposed to work.

That's best explained with an example, I think :)

Let's assume your output folder is selected as:
C:\Some Output Folder

Also let's assume you are converting the following source files:
C:\My Music\1st Artist\Song 1.mp3
C:\My Music\2nd Artist\Song 2.mp3
D:\Foobar\Test\Rnd32\Whatever.mp3

Normally LameXP would create these output files:
C:\Some Output Folder\Song 1.mp3
C:\Some Output Folder\Song 2.mp3
C:\Some Output Folder\Whatever.mp3

With "prepend relative source file path to output file" enabled, you will get these instead:
C:\Some Output Folder\My Music\1st Artist\Song 1.mp3
C:\Some Output Folder\My Music\2nd Artist\Song 2.mp3
C:\Some Output Folder\Foobar\Test\Rnd32\Whatever.mp3

Othniel Graichen

2nd November 2011, 22:33

>>The values were limited to a "sane" range. Why do you want to force LAME to use such ultra-low bitrates?

I am a Linux cmd line kinda guy. LameXP GUI is new to me. Here is my "NORMAL" command line to process voice recordings:

lame --resample 11 -b 8 -V 9 -a FM103-3_102911_003.wav

Sometimes I include the --preset voice switch -- mostly not.
I work with voice recordings transmitted over FM.

For VBR to work right -- you must let LAME decide the appropriate bit rate. -b specifies the minimum and -B the maximum. 32 is the default for -b so VBR cant take advantage of 24, 16 and 8 encodings unless you enable this via switch.

Othniel Graichen

LoRd_MuldeR

2nd November 2011, 23:09

AFAIK, VBR mode woks just fine without -b and -B. In that case LAME will simply use its default minimum/maximum bitrates for your 'VBR' quality value.

So IMO you shouldn't overwrite these, unless you have a very good reason to do so. The documentation even states that "the use of -B is NOT RECOMMENDED".

Also, as mentioned before, the lowest bitrate allowed in MP3, according to MPEG-1, is 32 kbps.

Even lower bitrates are only supported with MPEG-2 extensions. And even then only for 16, 22.05 and 24 kHz, but not for the more common sample rates, like 44.1 or 48 kHz.

Last but not least and most important:

I encoded a 44.1 kHz file with LAME and "-V9" (no other options set!). LAME encoded at 22.05 kHz. The output MP3 file did contain 8, 16 and 24 kbps frames!

Hence LAME will automatically downsample the input for such ultra-low quality settings. And, if it does so, it will make use of the lowest bitrates - even without '-b' option ;)

(BTW: You may want to check out MPEG Audio Info (http://sourceforge.net/projects/lamexp/files/Miscellaneous/MPEG%20Audio%20Info/MPEGAudioInfo.2011-04-24.zip/download), which gives detailed per-frame info, to analyze the output MP3 files.)

Taurus

2nd November 2011, 23:59

LoRd_MuldeR

3rd November 2011, 00:28

Out of curiosity I gave the FHG aac encoder a shot.
Maybe this has been adressed before:
Why is the slider in the compression settings tab only working at insane intervalls?
From level 0.50 to 0.9 there is almost no increase in bitrate
and even 1.0 is giving me a file undersized compared to the source.
The FHG files are from the newest 5.622 Winamp.
Back to nero for now.:p

As the FHG encoder is ClosedSource, only one of the Winamp/FHG engineers could answer this question :p

All that LameXP can do is passing options to the API provided by the encoder. And the VBR quality selector of the FHG encoder is relatively coarse-grained:

The quality value can be selected between 1 and 5, integer (whole numbers) only. The quality selector of the Nero encoder is much more fine-grained, as you know...

(Note that the quality slider in LameXP was designed for Nero AAC. For FHG AAC the values in range 0.0 to 1.0 are mapped to 1...5 in a linear fashion)

Othniel Graichen

3rd November 2011, 01:39

AFAIK, VBR mode works just fine without -b and -B. In that case LAME will simply use its default minimum/maximum bitrates for your 'VBR' quality value.

Also, as mentioned before, the lowest bitrate allowed in MP3, according to MPEG-1, is 32 kbps.

Even lower bitrates are only supported with MPEG-2 extensions.

I stand corrected. Thank you. I like to learn.

However, I am aware that I am utilizing MPEG-2.5 extensions. Maybe LAMExp should have another checkbox under the Additional Options tab in the channel mode/sampling rate box called "Enable MPEG-2.5".

When such a box is checked, 8, 11.025 and 12 kHz should be available in the sample rate pull-down box. I suggest also that the minimum bitrate field be set to 8 when MPEG-2.5 is enabled.

The application is not theoretical but that of mp3 audiobooks and
voice recordings.

Taurus

3rd November 2011, 08:22

Thank you:thanks:

LoRd_MuldeR

4th November 2011, 11:20

I stand corrected. Thank you. I like to learn.

However, I am aware that I am utilizing MPEG-2.5 extensions. Maybe LAMExp should have another checkbox under the Additional Options tab in the channel mode/sampling rate box called "Enable MPEG-2.5".

When such a box is checked, 8, 11.025 and 12 kHz should be available in the sample rate pull-down box. I suggest also that the minimum bitrate field be set to 8 when MPEG-2.5 is enabled.

The application is not theoretical but that of mp3 audiobooks and
voice recordings.

I don't think we need yet another option. LAME doesn't have a switch for that either. It's as simple as that: When encoding to a sample rate that is only supported in MPEG-1 (32, 44.1 or 48 kHz), LAME will create a MPEG-1 MP3 stream. When encoding to a sample rate that is only supported in MPEG-2 (16, 22.05 and 24 kHz), LAME will create a MPEG-2 MP3 stream. And when encoding to a sample rate that is only supported in MPEG-2.5 (8, 11.025 and 12 kHz), LAME will create a MPEG-2.5 MP3 stream. For 99.9% of the user this difference doesn't even matter (and thus we should confuse them with different MPEG standard versions). Moreover, in any case, LAME will make use of all supported bit rates (for the current sample rate), at least when encoding in VBR mode. There is no need to use -b or -B to "enable" additional bit rates. Instead these options can be used to further restrict the bit rates that VBR mode can choose from! And thus you should only be using them, if you have a very good reason to do so. Otherwise trust LAME's VBR algorithm...

http://img854.imageshack.us/img854/3479/cwindowssystem32cmdexe2l.th.png (http://img854.imageshack.us/img854/3479/cwindowssystem32cmdexe2l.png) http://img228.imageshack.us/img228/2352/cwindowssystem32cmdexe2f.th.png (http://img228.imageshack.us/img228/2352/cwindowssystem32cmdexe2f.png)

MadRat

6th November 2011, 10:17

As always in this situation: Please re-scan the suspicious file at http://www.virustotal.com/ to be sure it isn't really infected.

Then report the FALSE POSITIVE to the developer of your AntiVirus software. And, if they don't fix the problem, switch to a better product.

(I can't do anything about the issue, because it is impossible to know what aspect of LAME triggers the failure in their software)

It seems to be a false positive.

File already submitted: The file sent has already been analysed by VirusTotal in the past. This is same basic info regarding the sample itself and its last analysis:
MD5: 1aad0bc496cf8bd07b86ebc11bdb8a33
Date first seen: 2011-11-02 20:48:41 (UTC)
Date last seen: 2011-11-02 20:48:41 (UTC)
Detection ratio: 0/43

Thank you, for being patient.

LoRd_MuldeR

6th November 2011, 13:38

Result: 0 /43 (0.0%) (http://www.virustotal.com/file-scan/report.html?id=8e6b100d56f79eab6f6611b7f7f9d7d710a306b4e145012579835ec4bd66b4f5-1320266949)

Clearly a FALSE POSITIVE :)

Interestingly the "Symantec" scanner, which is the company behind "Norton", also confirms that the file is clean.

Maybe the issue has already been fixed ???

ikuban

11th November 2011, 07:07

Is the new RMS equalization mode similar to a dynamic range compression?

manolito

11th November 2011, 09:38

Is the new RMS equalization mode similar to a dynamic range compression?
No, the dynamic range of the source is not touched by this option. What is getting changed is the balance between the different channels of a multichannel source. Here is a quote from the SoX manual regarding the gain -nb effect:
Given the −e option, the levels of the audio channels of a multi-channel file are ‘equalised’, i.e.
gain is applied to all channels other than that with the highest peak level, such that all channels
attain the same peak level (but, without also giving −n, the audio is not ‘normalised’).

The −B (balance) option is similar to −e, but with −B, the RMS level is used instead of the peak
level. −B might be used to correct stereo imbalance caused by an imperfect record turntable car-
tridge. Note that unlike −e, −B might cause some clipping.

−b is similar to −B but has clipping protection, i.e. if necessary to prevent clipping whilst
balancing, attenuation is applied to all channels. Note, however, that in conjunction with −n, −B
and −b are synonymous.

Cheers
manolito

LoRd_MuldeR

11th November 2011, 12:17

Is the new RMS equalization mode similar to a dynamic range compression?

Well, kind of, I would say.

It does not compress the dynamic range "inside" on channel. That is: All samples in one channel will always be amplified by the same factor.

However one channel may be amplified stronger than the other ones, which possibly (not necessarily) changes the dynamic range "between" the channels - that may be desired or not.

(Be aware that, due to a bug(?) in SoX, the plain "-n" option files for some files, which was all the reason to use "-nb" by default)

manolito

11th November 2011, 14:27

(Be aware that, due to a bug(?) in SoX, the plain "-n" option files for some files, which was all the reason to use "-nb" by default)
Oh yes, this is a SoX bug which has been there for some time. Have a look here:
http://sox.sourceforge.net/Docs/Bugs

The recommended workaround is:
Create a folder called `tmp' at the top level of the `C:' drive (and any other drive from which SoX may be invoked).

But this workaround does not work at all. And SoX has not been updated since February 2011, so there is not much hope that this bug will get fixed anytime soon...:rolleyes:

Which makes me think if it would be a good idea to ditch SoX for normalizing altogether...

Cheers
manolito

LoRd_MuldeR

11th November 2011, 15:12

I think that's another issue.

LameXP already tells SoX to put temporary files into the LameXP Temp folder, which lies inside %TEMP% and therefore has no problems with file permissions.

The problem is more that normalization with just "-n" works most of the time, but sometimes creates an empty file without an error message...

(BTW: Whoever tries to create a sub-folder for temporary files in the Root folder of the system drive and then wonders about missing permissions doesn't have a clue. That wouldn't work on a Unix system either - at least not without using 'sudo'. It's certainly not a Vista/UAC-specific issue)

manolito

11th November 2011, 18:09

The problem is more that normalization with just "-n" works most of the time, but sometimes creates an empty file without an error message...
For me it does not look like sometimes. For a 6-ch wav file (no matter if the file is in the extensible format or not) SoX always creates an empty file without an error message, while for a 2-ch wav file SoX always works like it should.

I did many tests to determine this behavior, and these tests were done from the SoX command line (completely outside of LameXP). For 6-ch wav files the error was always something like "Could not create temporary device".

Cheers
manolito

LoRd_MuldeR

11th November 2011, 18:29

Well, I was able to reproduce the problem with some multi-channel (here I mean: more than two channels) files, but not with all. Also I never saw an error message, only an empty file.

If you see "Could not create temporary device", then please try with --temp . so that SoX will put the Temp file into the current directory...

Motenai Yoda

12th November 2011, 08:19

I notice that sometimes normalizing by peak don't work well, analyzing the result file with audition it finds peaks over -0.5dB..

Edit: It's a lack of lossy compression

Hobbe

12th November 2011, 10:04

Thanks for the new version... But I get this error when I tried to encode a mp3 with album art..
unsupported image: 'C:\Users\*****\AppData\Local\Temp\7f6f2bd55a3e4905a01d7d2723996b41\735d2eb984d746819396f5d3289e3cf8.jpg'.
Specify JPEG/PNG/GIF image

Exited with code: 0x0001

Does't lame support jpg at all? or is it just a problem with this file?

LoRd_MuldeR

12th November 2011, 12:35

Hello, Hobbe. As you didn't post the complete log, it's a bit hard to guess.

But it looks like LameXP (or MediaInfo to be more precise) found a JPEG image in the input file (or you manually added cover art in LameXP's MetaInfo editor), but then the encoder (LAME?) refused to embed that picture into the output file.

Unless you provide an example, I can only speculate that either the JPEG file is broken/incomplete somehow or what appears to be a JPEG file at first glance turns out to not be a JPEG file...

(You may want to open 'C:\Users\John Doe\AppData\Local\Temp\xxxx\yyyy.jpg' in IrfanView (http://www.irfanview.de/) and check what happens)

Hobbe

12th November 2011, 13:16

LoRd_MuldeR

12th November 2011, 13:30

Thanks... I did use mp3tag to add album art. This time I scaled down the picture to a smaller size and readded the art and now it works.. strange..

Can I add album art directly in LameXP? if so... how? =)

Meta Data editor. Add the file, then click "View Details" and "Artwork". In the Artwork view, you can click "Edit" to load/change the album art.

Any plans to make it possible to use Quicktime encoder?

You probably mean the QuickTime/iTunes AAC encoder?

Well, I certainly can't include the QuickTime AAC encoder with LameXP due to licensing issues. If there is some OpenSource CLI front-end available for QuickTime AAC, I could add support for that in a similar way to FHG AAC encoder. Which means that people would still have to download and install QuickTime from the official web-site. Then copy the encoder DLL's to the correct place manually.

But due to a deep-rooted antipathy against QuickTime products, that probably won't happen soon ;)

Hobbe

12th November 2011, 16:55

Thanks for letting me know.. I have completely missed that! =)

Ok. I understand.. I have the same feeling like you regarding Quicktime.. But it produce great sounding aac files :)
Meanwhile, I'll try to use the FHG aac encoder :D

LoRd_MuldeR

12th November 2011, 21:41

LameXP v4.03 R2 has been released :)

Changes between v4.02 and v4.03:
* Added an option to rename the output files (based on an user-defined naming pattern)
* Added an option to enforce Stereo Downmix for Multi-Channel sources
* Added "built-in" WMA decoder (see this (http://forum.doom9.org/showthread.php?t=140273) thread for details) and removed all remnants of "old" decoder
* Added optional support for the FHG AAC Encoder included with Winamp 5.62 (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added a menu for bookmarking "favorite" output folders to the "output folder" tab
* Added an option to hibernate the computer (aka "Suspend-to-Disk") instead of shutting it down
* Added Polish translation, thanks to Sir Daniel K <sir.daniel.k@gmail.com>
* Added channel equalization options to the normalization filter (also fixes multi-channel processing)
* Added indicators for current CPU usage, RAM usage and free diskspace to the processing window
* Updated Qt runtime libraries to v4.8.0 RC-1 (2011-10-13), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.1 Final (2011-11-05), compiled with ICL 12.1.6 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.133))
* Updated mpg123 decoder to v1.13.4 (2011-09-07), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.51 (2011-11-11), compiled with ICL 12.1.6 and MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Improved "downmix" filter by using explicit channel mappings for each number of input channels
* Fixed a potential bug in CPU type detection that might have caused the wrong binary to be used
* Fixed Cue Sheet import for tracks with certain characters in the title
* Fixed a bug with "Prepend relative source file path to output file" under certain conditions
* Workaround for malicious "anti-virus" programs that prevent innocent applications from functioning
* Enabled "Aero Glass" theme in installer and web-update program (Vista and Windows 7 only)
* Restored Windows 2000 support with Visual Studio 2010 builds (this is experimental!)
* The "Open File(s)" and "Open Folder" dialogs will now remember the most recent directory
* Miscellaneous bugfixes

No important changes since the first v4.03 release. Just updated the LAME and MediaInfo binaries to the latest versions.

mike20021969

12th November 2011, 21:55

LoRd_MuldeR

12th November 2011, 22:06

After installing an update, I always have to set my personal preferences again - the output folder, disable sounds, uncheck .m3u option, disable shell integration etc...
Is it possible that when an update is installed that preferences are remembered?

This would be a welcome addition to this great program.
Thanks.

Possible, yes. But currently the settings for each version are store separately. And there is a reason for this ;)

Some settings change their range/meaning between different versions and, the way it currently is implemented, a rude surprise is avoided.

After all, I should implement an automatic "import" function that will import settings from previous versions - if and only if possible.

(Nonetheless, if you only install major updates, then you won't update and thus loose your settings very often. So this isn't high priority)

Caroliano

15th November 2011, 16:27

The Web Update and instalation windows should not be aways on top of everything... I'm writing it right now with the download window above the textbox...

Besides that, this is my favorite audio encoding tool. Thanks for the update!

LoRd_MuldeR

15th November 2011, 16:36

I made the Installer and Web Updater windows "top most", because Windows has the annoying tendency to show the GUI of newly created processes in the background.

Having to minimize all other windows in order to find the Installer (or Updater) window may be very confusing, especially to less experienced users.

Therefore I think making those windows "top most", in order to ensure they will be visible right away, is the the lesser of two evils. Also: How often do you install/update LameXP?

Unless you use Beta updates, you shouldn't see the updater more often than once every 2 or 3 months. And, while updating, focusing on the Updater isn't the worst thing...

(You can minimize the updater at any time, of course. Probably makes sense only, if your internet connection is extremely slow)

LoRd_MuldeR

18th November 2011, 22:07

Diary of an GUI developer :p

A small excursion: LameXP uses "background" threads to monitor the encoder/decoder processes (e.g. LAME or OggEnc2) in real-time. A "background" thread will read and parse all text output that its encoder/decoder process writes to the STDOUT or STDERR. And, as soon as the process has written a progress update, the "background" thread emits an update signal. The update signal will then be processed in the "main" (GUI) thread's event loop, causing the progress indicator to be updated. Until now, each "background" thread was emitting update signals as soon as possible and even if the progress hadn't changed at all. It has to be noted that some encoder/decoder processes write a whole lot of status messages to their STDOUT/STDERR, often resulting in the same progress value (percentage) being reported multiple times. This happens, for example, if the progress hasn't changed between two (or more) consecutive status messages. Unfortunately as a result our "background" threads will emit update signals at a high rate! While playing around with the profiler (AMD CodeAnalyst), it came to my attention that the LameXP front-end process was eating a substantial amount of CPU time, in certain cases. It was obvious that this was caused by too many update signals being emitted/processed. For this reason I implemented update signal coalescing today. This means: Now a "background" thread will emit an update signal if and only if the progress has increased by at least 3% - relative to the previous update signal that has been emitted. Depending on the individual encoder/decoder, this significantly reduces the amount of update signals the "main" thread has to process, which clearly reduces the CPU time consumed by the LameXP front-end process. That CPU time is now available to the encoder/decoder processes, which will speed-up the overall process, or to other processes running on the system. It comes at cost of slightly delayed progress indicator updates.

This CPU usage graph shows the CPU load produced by the LameXP front-end process for the very same transcoding job, before (left) and after (right) the optimization:
http://img823.imageshack.us/img823/3078/lamexpsignalcoalescing.th.png (http://img823.imageshack.us/img823/3078/lamexpsignalcoalescing.png)

And here is a more detailed analysis of the CPU time consumption for all processes running on the computer while transcoding, before (left) and after (right) the optimization:
http://img88.imageshack.us/img88/6562/lamexpsignalcoalescinga.th.png (http://img88.imageshack.us/img88/6562/lamexpsignalcoalescinga.png)

(That's a reduction of LameXP's CPU time consumption to 1/5 in this particular case - using 'mpg123' as decoder and 'OggEnc2' as encoder)

Chikuzen

20th November 2011, 01:34

If there is some OpenSource CLI front-end available for QuickTime AAC, I could add support for that in a similar way to FHG AAC encoder.

http://tmkk.pv.land.to/qtaacenc/
http://sites.google.com/site/qaacpage/ :p

LoRd_MuldeR

20th November 2011, 01:53

http://tmkk.pv.land.to/qtaacenc/
http://sites.google.com/site/qaacpage/ :p

Thanks! I will have a look at that one. Though, as said before, adding support for QuickTime AAC is not a priority for me ;)

VzK

22nd November 2011, 20:17

These probably are dumb questions/suggestions:

Every time I open LameXP I have to clear 'Comment' field from Meta Data, it doesn't memorize the blank deleted info, both portable/install versions.
Then again when I'm editing tag infos on foobar there is always "LAME 32bits version 3.99.1 (http://lame.sf.net)" written in <encoding settings>. It would be cool if this could be personalized.

Regarding 32bits - I'm running under win7 x64 and it works fast without any problem but since there is a LAME 64-bit version available wouldn't make sense that be included/used?

I had the last version updated from the manager and today I noticed 'Adjust Bass (dB)' @ -1,00 and I'm positive I didn't change it.

It would be cool if it was possible to drag a .cue file instead of using the import tool. Lazy, I know.

Thanks for this indispensable app.

LoRd_MuldeR

22nd November 2011, 20:46

Hello, VzK.

Every time I open LameXP I have to clear 'Comment' field from Meta Data, it doesn't memorize the blank deleted info, both portable/install versions.
Then again when I'm editing tag infos on foobar there is always "LAME 32bits version 3.99.1 (http://lame.sf.net)" written in <encoding settings>. It would be cool if this could be personalized.

LAME adds that signature to the ID3v2 tag all by itself, it's not triggered by LameXP.

It's probably a help for the developers. So if somebody sends in a "problematic" file to the LAME developers, they can easily know form which LAME version that file originated.

Even if I could, I wouldn't modify LAME to suppress its signature. And I wonder what you want to hide? It doesn't leak any person information!

Regarding 32bits - I'm running under win7 x64 and it works fast without any problem but since there is a LAME 64-bit version available wouldn't make sense that be included/used?

LameXP already contains a SSE2-optimized build (Intel-only) of LAME and a generic 'IA32' build with SSE2 runtime CPU-dispatching.

Including a 64-Bit build "just because we can" isn't a good idea. It would make LameXP.exe even bigger.

And, as the 64-Bit builds of LAME currently can't be build with Assembler-optimizations enabled, they would probably be even slower...

(I did a test with various compiler settings a while ago and the 64-Bit build was the slowest on my system)

I had the last version updated from the manager and today I noticed 'Adjust Bass (dB)' @ -1,00 and I'm positive I didn't change it.

You probably changed it accidentally with the Mouse Wheel when scrolling down the Advanced Options page, seriously ;)

(If not, I'll investigate it, as soon as you give me detailed instructions on how to reproduce the issue)

It would be cool if it was possible to drag a .cue file instead of using the import tool. Lazy, I know.Thanks for this indispensable app.

LameXP uses MediaInfo to detect the type of a file.

That's why you can throw a bunch of files onto LameXP and still it will be able to tell the type of each file and select the suitable decoder.

That's not possible with Cue Sheets, because these are simple Text files.

Well, we could try to guess that a file with extension .cue is a Cue Sheet, but file extensions are not unambiguous and might even be "wrong".

LoRd_MuldeR

23rd November 2011, 01:02

Here is experimental QAAC (Apple QuickTime/iTunes AAC encoder) support :)

You will need to install the QAAC Add-in for LameXP from this location:
http://www.mediafire.com/file/8ifdnygiab4z5po/LameXP.qaac-addin.2011-11-22.zip

Last but not least, if you do not have an up-to-date QuickTime or iTunes installed yet, you will have to download and install that too :o

(Note: If both, Nero AAC and QAAC, are available, then LameXP will give preference to QAAC for now!)

LoRd_MuldeR

1st December 2011, 23:42

LameXP v4.04 Alpha-6:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.51+ (2011-11-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))

littleD

4th December 2011, 11:40

LoRd_MuldeR

4th December 2011, 14:13

Hello Lord Mulder, do you take in account Intel Hyperthreading? When i was compressing on corei3mobile 2cores/4threads with two cores set in lamexp, my cpu wasnt full utilised. When i set to 4 cores, cpu went on 100% and compressing was faster. Not big deal cause we can manualy set this option, but since you automate parallel instance count, You might consider Hyperthreading too. Wonder if same apply to bulldozer.

In general, Hyperthreading doesn't need any kind of special support. In theory, all applications with multi-core support will benefit automatically. So does LameXP :)

Hyperthreading simulates two "logical" cores for each "physical" one. But from the operating systems point of view, HT just doubles the number of CPU cores.

In "Auto" mode, LameXP will detect the number of CPU cores (using the GetNativeSystemInfo (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724340%28v=vs.85%29.aspx) function ) and adjusts the maximum number of parallel instances accordingly.

The number of CPU cores reported by GetNativeSystemInfo() should include all CPU cores, e.g. on a Quadcore with HT enabled, it should report eight cores.

Consequently on your Dualcore "Core i3 Mobile" with HT - if it really does have HT (isn't that for the i5 M's only?) - LameXP should detect and use four cores/instances.

Still this is only a maximum! That maximum number of parallel instanced can only be reached, if the number of files transcoded "at once" is at least as high as the maximum.

Moreover: Up to and including LameXP v4.03, the upper bound for the maximum number of instances was four! I implemented a less restrictive formula in LameXP v4.04.

(Also note that, if you overwrite LameXP's decision by manually setting the number of instances, it will run exactly the number of instances you have configured!)

For details please see:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0

littleD

4th December 2011, 20:38

Yes, it works as u say in stable 4.03 release. My last version i used was beta-6 snapshot and i wasnt sure if my cpu threads was recognized properly. Now i can't verify, beta expired :) And nice cpu/ram usage indicator addon btw :)
First mobile hyperthreaded cpu was intel's 1st gen corei3 series if any wanna know.

LoRd_MuldeR

4th December 2011, 21:25

Note that you can always run LameXP with "--console" option to check the number of CPU cores that have been detected.

Output should look like this:
CPU vendor id : GenuineIntel (Intel: 1)
CPU brand string : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz
CPU signature : Family: 6, Model: 15, Stepping: 7
CPU capabilities : MMX: 1, SSE: 1, SSE2: 1, SSE3: 1, SSSE3: 1, x64: 1
Number of CPU's : 4

LoRd_MuldeR

4th December 2011, 23:31

LameXP v4.04 Alpha-7:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.51+ (2011-11-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)

Brazil2

7th December 2011, 13:28

Then again when I'm editing tag infos on foobar there is always "LAME 32bits version 3.99.1 (http://lame.sf.net)" written in <encoding settings>. It would be cool if this could be personalized.
The encoding settings tag can be removed using the -t parameter:

-t disable INFO/WAV header

Disable writing of the INFO Tag on encoding.
This tag in embedded in frame 0 of the MP3 file. It includes some information about the encoding options of the file,
and in VBR it lets VBR aware players correctly seek and compute playing times of VBR files.

When '--decode' is specified (decode to WAV), this flag will disable writing of the WAV header.
The output will be raw PCM, native endian format. Use -x to swap bytes.

This is having a funny side effect though: if the encoding settings tag is present then the LAME version is reported with an "r" at the end (e.g. 3.98r, 3.99r), but if it's disabled then the full version of the encoder is shown (e.g. 3.98.4, 3.99.3). At least it works like that with LAME versions provided by Rarewares (http://www.rarewares.org/mp3-lame-bundle.php) and Jacek Pazera's Lame Front-End (http://www.pazera-software.com/products/lame-front-end/).

LoRd_MuldeR

7th December 2011, 21:39

These are two different things:

The so called "LAME header" is an extension of the good old "Xing/Info header". The format of the extended Xing header is described here:
http://gabriel.mp3-tech.org/mp3infotag.html

In the LAME tag there are only 9 characters for the version info. The format for the 'VersionString ' field used to be "LAME3.XXr", but there was some confusion about that recently:
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=91372&view=findpost&p=775750

At the same time, the "long" version string, such as "LAME 32bits version 3.99.1 (http://lame.sf.net)", is included in a normal id3v2 tag.

ID3 (version 2) Tag:
http://img202.imageshack.us/img202/2999/zynamicshexer1402011120.png

Xing+LAME Header:
http://img248.imageshack.us/img248/2999/zynamicshexer1402011120.png

VzK

8th December 2011, 06:53

LoRd_MuldeR, thanks for the exhaustive answer.

One more thing:
http://i.imgur.com/Y2nU7.png

I read that foreign characters are supported, did I do something wrong?
»single flac to various mp3 » import cue sheet » write meta info to encoded files option, no m3u file generated. Used v4.04 Alpha-7.

LoRd_MuldeR

8th December 2011, 13:34

Could you upload/attach the problematic CUE file please as-is?

LameXP handles Unicode characters properly, as long as the input is in the proper UTF-8 (http://en.wikipedia.org/wiki/Utf-8) format. I suspect that this is not the case here :scared:

Currently LameXP will assume that the input is UTF-8, iff a BOM (http://en.wikipedia.org/wiki/Byte_order_mark) is found. Otherwise it will interpret the input with your local 8-Bit Codepage (http://en.wikipedia.org/wiki/Code_page) - whatever that may be.

I know this this isn't very reliable, but storing text files with some local 8-Bit Codepage is extremely error-prone anyway, because for the app reading the file later, it will be impossible to know the correct Codepage. Assuming that the "local" Codepage is the right one, is just a wild guess. But probably the best we can do.

Using Unicode with proper UTF-8 encoding is the right way to store text files that contain "foreign" (Non-ASCII) characters! And a BOM should be prepended to indicate that this is UTF-8. Still the BOM is optional. Assuming that all text without a BOM is not UTF-8, is another wild guess. But again I don't know a better way...

(BTW: As for the console, you won't see proper Unicode output there anyway, unless you change font to "Lucidia Console")

[Small Update]

I hacked together a quick workaround that may work for your case:
http://www.mediafire.com/file/pqfj5ok7ogsuahn/LameXP.2011-12-08.Release-Static.Build-803.exe

If LameXP assumes that the input is not UTF-8, it will now test whether decoding the input with the "local 8-Bit" Codepage results in any '�' (U+FFFD) characters. In that particular case we can assume that the "local 8-Bit" Codepage is not the suitable one and thus we will fall back to the "Latin-1" Codepage. There is absolutely no guarantee that the Latin-1 Codepage will work any better than the local one. It's just another try (and will succeed with Western European encodings).

VzK

8th December 2011, 15:41

http://i.imgur.com/LWWr7.jpg
http://i.imgur.com/EyMfa.png

Original cue attached if you want to give a look anyway.

Great work LoRd_MuldeR! Thanks a lot!

LoRd_MuldeR

8th December 2011, 15:58

As I had assumed, your CUE file is not Unicode/UTF-8, but plain Latin-1 ;)

On an English or German version of Windows (actually many more), the Latin-1 Codepage is configured as the "local" Codepage by default.

That's why, on such systems, decoding the file with the "local" Codepage gives the desired result. And one might assume that this is always the case.

But it's not! Other localized versions of Windows have a different Codepage configured by default, giving potentially very different output :angry:

Solution: Open the CUE file in Notepad++, change the Encoding to the suitable one (here Latin-1) and then convert to UTF-8 (Unicode), with BOM.

LoRd_MuldeR

9th December 2011, 01:41

LameXP v4.04 Alpha-7.1:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.51+ (2011-11-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)

Dogway

9th December 2011, 12:34

I wanted to ask if you are going to implement an option for audio alignment. I had a .wav, encoded with LameXP to AAC, decoded to WAV back again, and compared both WAV in Audacity, and the second one had around 36ms positive delay. I didn't know this so everything I have done til now might be wrong :eek:
I was also looking for a list to know which encoders/decoders you use for each format.

I gathered some links of interest.

Questions about H.264 sync
http://forum.doom9.org/showthread.php?t=156163
NeroAacEnc and delay added during encoding
http://forum.doom9.org/showthread.php?t=144346
audio delay with mp4box
http://forum.doom9.org/showthread.php?t=145435
Possible bug in nero encoder?
http://forum.doom9.org/showthread.php?p=1420989
Audio Sync for MP3 and AAC files in AVISynth
http://forum.doom9.org/showthread.php?p=1426169

LoRd_MuldeR

9th December 2011, 14:26

The extra delay is a common "problem" with (lossy) audio compression formats.

One reason for this is that these formats usually work with fixed-size (in samples) "frames", which they will transform into the frequency domain.

But, because of the properties of the transform, overlapped transforms must be used and a so-called "window" function must be applied on the samples first.

And for that reason, some extra samples before and after each frame are required. But before the very first frame, starting at the very first sample, there are none!

That's why the encoder will prepend some "silent" samples in front of the very first input sample. And also append some after the last input sample.

In the MP3 format, there is no "official" way to indicate how many extra samples were added, in order to have the decoder remove them. LAME has it's own way.

(Whether an individual MP3 decoder will respect LAME's extra info header, that's a different question ^^)

See also:
* http://cas.web.cern.ch/cas/Denmark-2010/Caspers/Tektronix%20%20primer%20on%20overlapping%20FFT%20signals%202009%20CAS2010.pdf
* http://lame.sourceforge.net/tech-FAQ.txt

Dogway

9th December 2011, 15:44

So good, so it is just as padding in video processing. Now I understood better but the question is, will you add an option for this?
And the next question, where can I see all the modules used for each format in LameXP in order to know the possible settings, flaws, pros, cons, etc whynots.

LoRd_MuldeR

9th December 2011, 16:38

So good, so it is just as padding in video processing. Now I understood better but the question is, will you add an option for this?

Add an option for what?

If an audio encoder prepends samples to the source, it does this for good reason. It's a consequence of how audio compression works (seep previous post).

There is no simple option to turn it off ;)

It is possible to cut off the padded samples later, after decoding. But only if the decoder can know how many samples had been added by the encoder.

And this is a decoder feature, which is out of scope for LameXP.

Unless, of course, we are talking about the decoding of the sources (original files) that you feed into LameXP for conversion.

Actually I'm not quite sure whether the individual decoders used in LameXP, e.g. mpg123 for MP3 files or FAAD for AAC files, do remove padding, if possible.

(At least for MP3 files encoded by LAME it is possible to accurately remove the padded samples at playback/decoding-time)

And the next question, where can I see all the modules used for each format in LameXP in order to know the possible settings, flaws, pros, cons, etc whynots.

What do you consider a module?

Anyway, all code of LameXP can be found at its Git repository:
https://github.com/lordmulder/LameXP

Dogway

9th December 2011, 18:16

Option to fix it. In post-processing for example, just an idea.

You don't know how the input was encoded, but you know how you are going to decode it (to wav) and encode it again. So there's room to make things nice in LameXP scope. I'm not sure, I just got to know about this bug (I consider it a bug) but I think the delay is a constant value (http://forum.doom9.org/showthread.php?p=1238245#post1238245)so with a few tests you can get to know. But it's up to you to decide if this is LameXP scope, right now I think I can't use it anymore for my videos audio. Now it's only useful for music audio, and individual tracks of course, if you encode a session composed of tracks LameXP won't be suited either...
Fortunately I now know about it, and can use workarounds, many people will still encode delayed audio without knowing aka doing the wrong thing.

In video processing we also add some padding for some filters to comply the mod 16 requirement, or just to protect borders. But the padding is always cropped back after filtering.

I think you call them Tools.
https://github.com/lordmulder/LameXP/tree/master/res/tools

You have some kind of a list more towards suppported formats rather than used tools for input/output formats
http://gitorious.org/lamexp/lamexp/blobs/987dce8c3b99540bc7671ad4635ed3887d71e999/doc/FAQ.html#line39

That can make the cut if I were to test for delay issues and flag options.

LoRd_MuldeR

9th December 2011, 19:49

Option to fix it. In post-processing for example, just an idea.

No, the "encoder delay" is not a bug. And thus there is no "fix" per se. As explained before, the padding is a direct consequence of how audio compression works. Let's not overstate things ;)

And to make that clear: Any MP3 encoder (e.g. LAME) will cause an "encoder delay", though the delay may differ between different encoders. Also the front-end (e.g. LameXP) has no influence on that.

The problem with MP3 in particular is that there is no "official" way to indicate the amount of padding that had been added by the encoder, so the decoder can't remove it!

AFAIK in the design of Vorbis this has been handled much better, i.e. the "encoder delay" is stored in the stream in a standardized way and thus it will be removed properly by the decoder.

I don't know what the situation with AAC is, but I guess it is more or less the same as with MP3...

Some more info:
http://en.wikipedia.org/wiki/Gapless_playback

You don't know how the input was encoded, but you know how you are going to decode it (to wav) and encode it again. So there's room to make things nice in LameXP scope. I'm not sure, I just got to know about this bug (I consider it a bug) but I think the delay is a constant value so with a few tests you can get to know. But it's up to you to decide if this is LameXP scope, right now I think I can't use it anymore for my videos audio. Now it's only useful for music audio, and individual tracks of course, if you encode a session composed of tracks LameXP won't be suited either...
Fortunately I now know about it, and can use workarounds, many people will still encode delayed audio without knowing aka doing the wrong thing.

The processing chain is as follows:
Decode input -> Apply filters (if any) -> Encode output

The "encoder delay" is added in the very last step, so it is impossible to implement any workaround, obviously. Except having LAME add it's header to the MP3 file - which it does by itself.

Actually I just made a quick test and, indeed, the 'mpg123' decoder will respect the LAME header. Thus, if a LAME header is present, the padding samples are removed :cool:

If you encode a Wave file to MP3 with LameXP (and thus with LAME) and then decode that MP3 file to Wave again with LameXP (and thus with mpg123), the sample count remains unchanged!

You can try yourself with:
lame.exe -V2 uncompressed.wav compressed.mp3
mpg123.exe -v -w decompressed.wav compressed.mp3

You will see that "uncompressed.wav" and "decompressed.wav" will have to exactly same size in bytes. And in the audio editor you can check that they are perfectly aligned.

That's as much as we can do :)

(If some other decoder will be used to decode the MP3 files produced by LameXP/LAME and that decoder ignores the LAME header, then we cannot do anything about that)

LoRd_MuldeR

10th December 2011, 19:42

LameXP v4.04 Alpha-8:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2011-12-10/

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.51+ (2011-11-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)

Found a bug that caused LameXP to never use the local 8-Bit Codepage when importing a Cue Sheet or Playlist. Instead UTF-8 was tried twice :o

This has been fixed. Also, when importing a Cue Sheet that is not UTF-8 with a proper BOM, LameXP will now allow the user to choose the desired 8-Bit Codepage.

For everybody who doesn't know what that means: You can simply keep "(System Default)" and click 'OK' when the Codepage dialog pops up ;)

VzK

10th December 2011, 22:43

Updated. :)

Found a typo:
http://i.imgur.com/Fs1Za.png

LoRd_MuldeR

10th December 2011, 23:15

Thank you. Fixed ;)
https://github.com/lordmulder/LameXP/commit/caabab7adf255f274350d4383bbf9d15f92e5bd1#diff-9

BTW, I added some info about the "encoder delay" to the F.A.Q document:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#c6d9dfed

Reimar

11th December 2011, 19:41

Using Unicode with proper UTF-8 encoding is the right way to store text files that contain "foreign" (Non-ASCII) characters! And a BOM should be prepended to indicate that this is UTF-8. Still the BOM is optional. Assuming that all text without a BOM is not UTF-8, is another wild guess. But again I don't know a better way...

I don't think that is correct, a BOM for UTF-8 to my knowledge is not only not necessary but actually invalid (it certainly does not serve as BOM, there is no byte order to mark for UTF-8).
In addition UTF-8 can be autodetected quite reliably, if you can parse it correctly as UTF-8 and you test text contains characters outside the ASCII range (>127) it almost certainly is UTF-8.

Dogway

11th December 2011, 20:04

Thank you. Fixed ;)
https://github.com/lordmulder/LameXP/commit/caabab7adf255f274350d4383bbf9d15f92e5bd1#diff-9

lol you never sounded so receptive when I noted similar typos... just curious : P

-Typo in Show Dropbox in Spanish would be "Mostrar DropBox"
Feel free to update the language file according to the translator's guide:
http://mulder.brhack.net/public/doc/lamexp_translate.html

mariush

11th December 2011, 20:36

I don't think that is correct, a BOM for UTF-8 to my knowledge is not only not necessary but actually invalid (it certainly does not serve as BOM, there is no byte order to mark for UTF-8).
In addition UTF-8 can be autodetected quite reliably, if you can parse it correctly as UTF-8 and you test text contains characters outside the ASCII range (>127) it almost certainly is UTF-8.

http://en.wikipedia.org/wiki/Byte_order_mark#UTF-8

0xEF,0xBB,0xBF is a valid combination to represent UTF-8 content.

The UTF-8 representation of the BOM is the byte sequence 0xEF,0xBB,0xBF. A text editor or web browser interpreting the text as ISO-8859-1 or CP1252 will display the characters ï»¿ for this.

The Unicode Standard does permit the BOM in UTF-8,[2] but does not require or recommend its use.[3] Byte order has no meaning in UTF-8[4] so in UTF-8 the BOM serves only to identify a text stream or file as UTF-8.

One reason the UTF-8 BOM is not recommended is that many pieces of software without Unicode support nevertheless are able to handle UTF-8 inside a text but not at the start of a text. For instance, the bytes of UTF-8 can be placed between the quotes of string constants in many programming languages, and that language will write the correct UTF-8 to a file or to a display, despite the language not knowing anything about UTF-8. This provides an easy migration path to convert systems to Unicode and to remove all legacy encodings, without simultaneously upgrading the programming language. The unexpected three bytes of the BOM break this however, as they are located where they are certain to be a syntax error.

A leading BOM can also defeat software that uses pattern matching on the start of a text file, since it inserts 3 bytes before the pattern. Though commonly associated with the Unix shebang at the start of an interpreted script,[5] the problem is more widespread. For instance in PHP, the existence of a BOM will cause the page to begin output before the initial code is interpreted, causing problems if the page is trying to send custom HTTP headers (which must be set before output begins).

Many Windows programs (including Windows Notepad) add BOMs to UTF-8 files by default[citation needed].

LoRd_MuldeR

11th December 2011, 20:43

@Reimar:
Yes, the BOM symbol in UTF-8 does not serve to indicate the Byte Order (there is no Byte Order in single-byte sequences, yes) and it's optional. Still it's a valid character and often present. So if an UTF-8 BOM is found, we can assume that the text is UTF-8 indeed. The probability to find a UTF-8 BOM sequence just "by chance" is negligible. In the other case, when there is no UTF-8 BOM present, the text may still be valid UTF-8. But it maybe "some" local 8-Bit codepage just as well. It may not even be encoded in the Windows ANSI Codepage that happens to be configured on the individual computer. For all these reasons, if no UTF-8 BOM is found, LameXP will now pop up a small dialog, allowing the user to select the desired Codepage.

@Dogway:
I'm always thankful for bug-reports, including typos. But, as a matter of fact, I can only update the English and German translations. For all other languages I have to rely on other people to send my updated/corrected language files :o

mariush

11th December 2011, 20:45

Mulder, ideally you should show a window with a preview updated automatically when use selects a different codepage from a drop down list...

LoRd_MuldeR

11th December 2011, 20:54

Mulder, ideally you should show a window with a preview updated automatically when use selects a different codepage from a drop down list...

Ideally I should. Practically I think that is "nice to have" but over the top :)

Brazil2

12th December 2011, 10:52

LameXP v4.04 Alpha-8:
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
FYI LAME v3.99.3 is out since 2011-11-26:
http://sourceforge.net/projects/lame/files/lame/3.99/lame-3.99.3.tar.gz/download
;)

LoRd_MuldeR

12th December 2011, 11:13

FYI LAME v3.99.3 is out since 2011-11-26:
http://sourceforge.net/projects/lame/files/lame/3.99/lame-3.99.3.tar.gz/download
;)

Compared to 3.99.2 there only was one minor fix that doesn't effect LameXP.
LAME 3.99.3 November 26 2011
Fix for tracker item [ 3441349 ] --tg does not handle genre number when adding unicode tag

(LameXP doesn't pass genres by number)

Reimar

12th December 2011, 22:52

@Reimar:
Yes, the BOM symbol in UTF-8 does not serve to indicate the Byte Order (there is no Byte Order in single-byte sequences, yes) and it's optional. Still it's a valid character and often present.

Yes, I was slightly off, it is not invalid it just is "not recommended".

In the other case, when there is no UTF-8 BOM present, the text may still be valid UTF-8. But it maybe "some" local 8-Bit codepage just as well. It may not even be encoded in the Windows ANSI Codepage that happens to be configured on the individual computer. For all these reasons, if no UTF-8 BOM is found, LameXP will now pop up a small dialog, allowing the user to select the desired Codepage.

Yes, that is a sensible solution. However the chances that a string containing a character of value > 127 parses as UTF-8 but is not UTF-8 is almost as negligible as the chances that something starting with UTF-8 BOM code is not UTF-8, since UTF-8 is a rather inefficient and wasteful encoding. (the first byte of value > 127 - which must at least have a value of 247 IIRC - indicates how many following bytes start with the bit pattern 10 - you'll have a hard time finding a word in any language in any encoding - except UTF-8 of course - that happens to conform to this).
For purely random data you should reach the same confidence as a UTF-16 BOM at about 8 bytes > 127 and the same as UTF-8 BOM at about 12.
But enough side-tracking, I'll shut up now and let you all get back to the topic.

LoRd_MuldeR

13th December 2011, 01:27

Yes, I was slightly off, it is not invalid it just is "not recommended".

Well, at least on Windows, having an UTF-8 BOM is quite common. For example, the Windows Notepad does add a BOM to UFT-8 files. Winamp does add it to .m3u8 playlists as well.

Last but not least, Notepad++ supports normal "UTF-8" (that is with BOM) and "UTF-8 without BOB" (aka "ANSI as UTF-8").

Yes, that is a sensible solution. However the chances that a string containing a character of value > 127 parses as UTF-8 but is not UTF-8 is almost as negligible as the chances that something starting with UTF-8 BOM code is not UTF-8, since UTF-8 is a rather inefficient and wasteful encoding. (the first byte of value > 127 - which must at least have a value of 247 IIRC - indicates how many following bytes start with the bit pattern 10 - you'll have a hard time finding a word in any language in any encoding - except UTF-8 of course - that happens to conform to this).
For purely random data you should reach the same confidence as a UTF-16 BOM at about 8 bytes > 127 and the same as UTF-8 BOM at about 12.
But enough side-tracking, I'll shut up now and let you all get back to the topic.

Deciding whether something will decode as valid UTF-8 or not isn't that trivial tough. Especially as I'm not planning to reinvent the wheel and implement my own UTF-8 decoder. Instead I just select the desired QTextCodec class and let it do its job. Also, as far as I understand, UTF-8 was designed in a way to allow for easy resynchronization after "invalid" or "missing" bytes. So decoding errors at one point don't necessarily mean that the rest can't be valid UTF-8...

ToMaZz

14th December 2011, 19:13

Hello again,

Is there any possibility to have .m4a extensions instead of .mp4 with NeroAAC codec? :rolleyes:
It is painfull because iTunes and some other apps treats mp4 as video file, so for example I cannot change cover for it like for m4a.

As a workaround I'm using some files renamer after every encoding with great LameXP. ;)

SeeMoreDigital

14th December 2011, 19:56

Hello again,
Hello again... This is your first post on the forum!

Is there any possibility to have .m4a extensions instead of .mp4 with NeroAAC codec?
LoRd_MuldeR has made it quite clear in the past that he wont do this

LoRd_MuldeR

14th December 2011, 21:27

Please see here:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#126abc5a

And here:
http://en.wikipedia.org/wiki/MPEG-4_Part_14#.MP4_versus_.M4A_filename_extensions

LoRd_MuldeR

14th December 2011, 22:11

LameXP v4.04 Alpha-9:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.51+ (2011-11-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)

Added proper support for UTF16 (LE and BE) encodings to the Playlist and Cue Sheet importer.

ToMaZz

14th December 2011, 22:51

Hello again... This is your first post on the forum!

It was on some LameXP/author homepage in the past - not on this forum.

Please see here:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#126abc5a

And here:
http://en.wikipedia.org/wiki/MPEG-4_Part_14#.MP4_versus_.M4A_filename_extensions

Thanks for reply. I see now that mp4 is correct extension.
..but still you can make life easier for users of LameXP by adding option of using incorrect m4a extension instead.
After weeks of using file renamer (allways after encoding) it is more and more irritating and painfull to do it manualy again.. and again.. and so on. ;)

LoRd_MuldeR

17th December 2011, 18:25

LameXP v4.04 Alpha-10

Added Chinese translation:
http://img585.imageshack.us/img585/429/lxpzh.jpg

LoRd_MuldeR

20th December 2011, 18:24

LameXP v4.04 Alpha-11:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.52 (2011-12-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)

LoRd_MuldeR

24th December 2011, 16:14

LameXP v4.04 Alpha-12:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.52 (2011-12-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)

ckmox

26th December 2011, 04:08

@LoRd_MuldeR

how to encode in WavPack? (http://www.wavpack.com/) or if their is no option for this can i make this as a request?

and i hope someday that LameXP can accept video inputs too so i do not have to demux the audio from the videos

Dogway

26th December 2011, 04:22

I just realised (out of necessity I guess), could you add an "exit program when finished" just like the shutdown checkbox?

LoRd_MuldeR

26th December 2011, 15:49

how to encode in WavPack? (http://www.wavpack.com/) or if their is no option for this can i make this as a request?

WavePack output is not supported yet, only input.

Didn't see much use for WavPack output, because FLAC provides very similar compression ratio and has much better support in both, hardware and software players.

It's more like a niche product that you may need to convert from now and then, but most people will/should never want to encode to that format.

(If enough people request WavPack encoding, I will consider adding it. So far, you are the first person though)

and i hope someday that LameXP can accept video inputs too so i do not have to demux the audio from the videos

Not really in the scope of LameXP. Nonetheless a "video import" wizard could be implemented, similar to the "Cue sheet import" wizard.

At least for some container formats, such as MP4 (via mp4box) and MKV (via mkvextract).

I just realised (out of necessity I guess), could you add an "exit program when finished" just like the shutdown checkbox?

What would be the use-case for this? :confused:

I see that when you run a longer encode (with lots of files) you may want to go away (or to bed) and keep the encoding process running.

Then it makes sense to shutdown/hibernate the system, as soon as everything is done - to save power.

But why would you want just the application to exit? What is the benefit? The CPU time and RAM used by LameXP while it's idle is negligible.

Also, if the application will exit on completion, you loose all the log/status information...

Dogway

26th December 2011, 21:06

I was downloading some stuff I knew it was going to take longer than the LameXP encoding, so I set a shutdown task at a given time. If it's ok LameXP being forced to exit by windows then don't add it.

LoRd_MuldeR

26th December 2011, 21:31

LoRd_MuldeR

27th December 2011, 04:32

When Windows is initiating a shutdown, it will send a WM_QUERYENDSESSION message followed by a WM_ENDSESSION message to all running applications.

I would assume that Qt processes these messages and closes the application's window (and thus exit the application) in order to allow the system to shutdown gracefully.

But I have not tested this yet. If it turns out that LameXP is blocking the system from shutting down, I will implement some workaround for this...

Update:

LameXP will not block Windows from shutting down, when the main window is showing or when the processing dialog is showing after all files have been processed.

However the processing dialog did block the shutdown when encoding is still in progress. This would be okay, if Windows didn't kill our encoder processes when the shutdown is initiated :scared:

It seems that Windows will rigidly kill all processes that have no own GUI window, so our encoder processes have no chance to react. Thus it makes no sense to keep the LameXP main process running.

For this reason I have hacked in a workaround that will force LameXP to quit as soon as possible, if the system is trying to shut down - even when encoding is not yet completed...

LoRd_MuldeR

29th December 2011, 16:22

LameXP v4.04 Alpha-13:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.52 (2011-12-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)

Be aware: Windows will rigorously kill all "console" applications, when the system is preparing to shut down. On Windows XP (and earlier) this also applies to GUI application that have a console attached! This means, if LameXP is running on Windows XP and if it has a console attached (the default with "Beta" builds), then it has no chance to do a final clean-up when the system is shutting down. According to M$, this is "by design" and not a bug! At least Windows 7, and probably also Vista, does not behave like this anymore, so LameXP will always do a proper clean-up on those. Last but not least, all "release" builds of LameXP should not be effected (unless you explicitly run with "--console" option).
__________________
"On Windows NT, the top-level window in an application that has called AllocConsole does not receive the WM_QUERYENDSESSION and WM_ENDSESSION messages."

LoRd_MuldeR

4th January 2012, 23:28

LameXP v4.04 Alpha-14:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2012-01-04/

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.52 (2011-12-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)

The CVS format looks like this:
POSITION;TITLE;ARTIST;ALBUM;GENRE;YEAR;COMMENT
1;Rausch;Dritte Wahl;Nimm Drei;Punk;1996;Kodiert mit LameXP
2;Greif Ein!;Dritte Wahl;Nimm Drei;Punk;1996;Kodiert mit LameXP
3;Kneif Mich!;Dritte Wahl;Nimm Drei;Punk;1996;Kodiert mit LameXP
4;Militär;Dritte Wahl;Nimm Drei;Punk;1996;Kodiert mit LameXP
5;Alles Vergeht;Dritte Wahl;Nimm Drei;Punk;1996;Kodiert mit LameXP
...

LoRd_MuldeR

14th January 2012, 02:58

LameXP v4.04 Alpha-15

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.52 (2011-12-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art

lethedoom

14th January 2012, 20:32

Hi Mulder,

As always I thank you for providing LameXP.

fyi when I installed Alpha-14 dated 1/4 there was already an update dated 1/5 to download and install which never seemed to be added to your sourceforge.net list. Today when I downloaded and installed Alpha 15 I found the Rename Output Files 'Rename Pattern' on the Advanced Options tab reset to [<TrackNo>] <Artist> - <Title> rather than carrying over the setting <Title> I had established on the updated iteration. This did not happen on the previous update.

lethedoom

LoRd_MuldeR

14th January 2012, 20:52

I don't upload all builds to the Sourceforge mirror. The auto-update server therefore is updated more frequently.

Also, when you install a newer build, your old settings are lost. Actually they are not lost, but each version stores its settings separately.

The vast majority of all users will only update when a new "final" version is out, so I never bothered changing this behavior...

LoRd_MuldeR

14th January 2012, 21:26

LameXP v4.04 Alpha-16:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.52 (2011-12-19), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art

This versions contains an updated MediaInfo binary that fixes a bug with the "--inform" parameter (see here (http://forum.doom9.org/showthread.php?p=1551524#post1551524) for details).

Hobbe

16th January 2012, 18:26

Not really in the scope of LameXP. Nonetheless a "video import" wizard could be implemented, similar to the "Cue sheet import" wizard.

At least for some container formats, such as MP4 (via mp4box) and MKV (via mkvextract).

I'm also requesting this feature!
Not many good and updated program that lets you just change audio codec. I often encode aac or ac3 from DTS and leave the video intact...

LoRd_MuldeR

26th January 2012, 15:58

LameXP v4.04 Alpha-17:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.53 (2012-01-24), compiled with ICL 12.1.6 and MSVC 10.0
* Updated Monkey's Audio to v4.10 (2011-04-16)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art

Xanderic

9th February 2012, 17:35

Just a quick question... I noticed the default encoding channel is set to Joint Stereo.. but I remember reading years ago that JS wasn't that good.. something about it not being implemented properly?... has that changed? Should I stick with Stereo or start encoding with Joint Stereo? and what's the difference with Forced Joint Stereo?

Thanks

LoRd_MuldeR

9th February 2012, 17:55

You are wrong:

The default is "Auto" mode, i.e. let the LAME encoder decide the "optimal" channel mode, based on the input audio and the target bitrate.

Joint Stereo can improve the compression efficiency quite a bit. That's why LAME uses it for "medium" and "low" bitrates. And you should trust LAME here ;)

At "high" bitrates though, the extra compression efficiency probably isn't worth the slightly worse Stereo separation caused by Joint Stereo.

Also, even if LAME decides to use Joint Streo, it will still switch between Joint Stereo and plain Stereo on a per-frame basis, depending on the input audio.

You can enforce the use of Joint Stereo in all frames by selecting the "Forced Joint Stereo" mode, but this is not recommended!

(About "not being implemented properly": As you don't say anything about who or what you think does not implement Joint Stereo properly, I have no idea)

Xanderic

9th February 2012, 17:59

Thank you very much for the quick response. I encode at 320 CBR so I guess it's relatively insignificant. I'll do a few more tests and see if I can hear any difference but I doubt it :).

Thanks again.

Xanderic

9th February 2012, 18:25

But this is where I get confused.. using "Auto" mode on "LameXP.2011-11-12.Release-Static.Build-774", when I put it into iTunes... it says "Channels: Joint Stereo" and "Encoded with: Unknown"

I just did 2 conversions... 1 english flac conversion and 1 chinese ape conversion ... any recommendations on what program I should use to analyze the information of the converted files?

I couldn't upload the screenshots so I uploaded to dropbox:
English: http://dl.dropbox.com/u/1363175/keane%20conversion.jpg
Chinese: http://dl.dropbox.com/u/1363175/leoku%20conversion.jpg

LoRd_MuldeR

9th February 2012, 18:49

But this is where I get confused.. using "Auto" mode on "LameXP.2011-11-12.Release-Static.Build-774", when I put it into iTunes... it says "Channels: Joint Stereo" and "Encoded with: Unknown"

What does it mean if iTunes says "Channels: Joint Stereo" ???

The very first MP3 frame in the file is Joint Stereo? There is at least one MP3 frame encoded as Joint Stereo in the file? All MP3 frames in the file are Joint Stereo?

Also: It's not very spurring that at least some frames were encoded as Joint Stereo in "Auto" mode.

I just did 2 conversions... 1 english flac conversion and 1 chinese ape conversion ... any recommendations on what program I should use to analyze the information of the converted files?

For some general info use MediaInfo! For details about MP3 files, use MPEG Audio Info:
http://sourceforge.net/projects/lamexp/files/Miscellaneous/MPEG%20Audio%20Info/

manolito

21st February 2012, 22:28

Good news! The latest SoX release candidate version 14.4.0rc3 did fix the old bug that the parameter "gain -n" screwed up normalization for multichannel files. Here is the log:

LameXP v4.03 (Build #774), compiled on 2011-11-12 at 16:13:26

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

Copy file "I:/Title1.wav" to "I://d4349fe33fa94bc5b533da544cdce4bc.wav"

Exited with code: 0x0000

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

E:/Programme/LameXP/tools/774/sox.exe -V3 -S --temp . I:\\d4349fe33fa94bc5b533da544cdce4bc.wav I:\\edcda78cbcba4818a3a3427361023840.wav gain -n -0.50

E:\Programme\LameXP\tools\774\sox.exe: SoX v14.4.0
E:\Programme\LameXP\tools\774\sox.exe INFO formats: detected file format type `wav'
E:\Programme\LameXP\tools\774\sox.exe INFO wav: EXTENSIBLE
Input File : 'I:\\d4349fe33fa94bc5b533da544cdce4bc.wav'
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 00:03:27.62 = 9965568 samples ~ 15571.2 CDDA sectors
File Size : 120M
Bit Rate : 4.61M
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
E:\Programme\LameXP\tools\774\sox.exe INFO sox: Overwriting `I:\\edcda78cbcba4818a3a3427361023840.wav'
Output File : 'I:\\edcda78cbcba4818a3a3427361023840.wav'
Channels : 6
Sample Rate : 48000
Precision : 16-bit
Duration : 00:03:27.62 = 9965568 samples ~ 15571.2 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
E:\Programme\LameXP\tools\774\sox.exe INFO sox: effects chain: input 48000Hz 6 channels
E:\Programme\LameXP\tools\774\sox.exe INFO sox: effects chain: gain 48000Hz 6 channels
E:\Programme\LameXP\tools\774\sox.exe INFO sox: effects chain: dither 48000Hz 6 channels
E:\Programme\LameXP\tools\774\sox.exe INFO sox: effects chain: output 48000Hz 6 channels
Done.

Exited with code: 0x0000

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

Copy file "I://edcda78cbcba4818a3a3427361023840.wav" to "I://Title1 (2).wav"

Exited with code: 0x0000

Which means that the temporary fix (using -ne or -nb) is no longer necessary. Very nice...:cool:

Cheers
manolito

LoRd_MuldeR

21st February 2012, 22:34

Thank you for the info. I will give the new version a try ASAP :)

Tough, unless they finally support Unicode on Win32 now, I will have to port my UTF-8 modifications to the new version first, before it can be used in LameXP.

LoRd_MuldeR

21st February 2012, 23:59

LameXP v4.04 Beta-1:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.53 (2012-01-24), compiled with ICL 12.1.6 and MSVC 10.0
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art

Vospi

22nd February 2012, 19:21

LoRd_MuldeR

22nd February 2012, 21:39

I've encountered a very bothersome trouble:

At some point LameXP began to show "Not found!" status for some files during encoding. This bug is totally random; for example, once the encode is finished, I can just drop the skipped files again and they will encode with no problems. Also, you can drop the same files and LameXP will skip something new this time.

I use v4.03 Final-2 (Build 774). Windows XP SP3 x86.

I really love the software and will be grateful for help.

You are the first one to report this problem. So what details does the log give for the "Not found!" items? :confused:

Do you have any Antivirus program with "real-time scanner" or "behavior scanner" or "guard" feature installed? If so, try to temporarily uninstall/disable it and see if that makes any difference.

Also: Is the problematic file located on some network drive or USB device? And does the problem still occur with LameXP v4.04 Beta-1 ???

LoRd_MuldeR

24th February 2012, 01:43

LameXP v4.04 Beta-2:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.53 (2012-01-24), compiled with ICL 12.1.6 and MSVC 10.0
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

LoRd_MuldeR

24th February 2012, 01:47

Today I made new builds of SoX from version v14.4.0rc3 with Unicode support:
http://www.mediafire.com/file/kdrdad4bram9cw2/SoX-v14.4.0rc3-Win32-UTF8.2012-02-24.zip

Please give it a test and report fixes (or regressions) compared to the old version.

manolito

24th February 2012, 20:09

Just did a few short test runs with the Unicode version of SoX. I converted a 6-ch wave file (FORMAT_EXTENSIBLE) to a normalized 6-ch wave file using the gain -n option. No problem, the resulting file looked alright to me.

I also converted the same source file to a normalized 2-ch wave file to make sure that the downmix option was not broken. No problem here, too.

I have no idea how to test if the Unicode support works. I gave my source file a funny name with all kinds of special characters plus some french accented characters, but the original (non-Unicode) version handled this file just fine.

One thing might need further investigating, though. I did the conversion from 6-ch to 6-ch normalized twice, once using the original version and once using your modified Unicode enabled version. The two resulting files should be identical, right? But they are not, even though I could not make out any audible difference.

Cheers
manolito

LoRd_MuldeR

24th February 2012, 20:31

I have no idea how to test if the Unicode support works.

If you want to test Unicode support, use a file name that cannot be represented in your computer's local ANSI codepage.

Or even better: Use a file name that contains characters from different ANSI codepages and thus can not be represented in the local ANSI codepage on any computer!

For examplem combine a few Cyrillic, a few Greek, a few Arabic, a few Nepalese and a few Chinese characters in the same file name ;)

One thing might need further investigating, though. I did the conversion from 6-ch to 6-ch normalized twice, once using the original version and once using your modified Unicode enabled version. The two resulting files should be identical, right? But they are not, even though I could not make out any audible difference.

In theory, they should be identical. But in reality, there can be minor differences due to different compilers or different compiler settings.

You can make a DIFF of the two files, e.g. in Cool Edit or a similar audio editor, by copying the one file to the clipboard and then using "mix paste" with "inverted" option to paste it into the other one.

That DIFF audio file should be pretty much silent. Otherwise we have a problem ;)

manolito

25th February 2012, 00:03

For examplem combine a few Cyrillic, a few Greek, a few Arabic, a few Nepalese and a few Chinese characters in the same file name ;)
OK thanks, I think I will leave these tests up to you...:rolleyes: Just confirms my suspicion that I really have no use for unicode.

In theory, they should be identical. But in reality, there can be minor differences due to different compilers or different compiler settings.

You can make a DIFF of the two files, e.g. in Cool Edit or a similar audio editor, by copying the one file to the clipboard and then using "mix paste" with "inverted" option to paste it into the other one.

That DIFF audio file should be pretty much silent. Otherwise we have a problem ;)
Yep, you are right, must be different compiler settings. The DIFF file was almost silent (RMS level -90 dB, one peak at -39 dB).

Cheers
manolito

LoRd_MuldeR

25th February 2012, 00:31

OK thanks, I think I will leave these tests up to you...:rolleyes: Just confirms my suspicion that I really have no use for unicode.

I guess you'd cry for proper Unicode support, as soon you get the error message that the program can't open file "?????" just because their happen to be some foreign characters in the name :p

manolito

25th February 2012, 03:01

I guess you'd cry for proper Unicode support, as soon you get the error message that the program can't open file "?????" just because their happen to be some foreign characters in the name :p
I don't think so. I started with computers in 1987 when filenames had to be in the 8.3 format. And I still prefer using short and simple filenames.

And if I come across a file with foreign characters in its name, I do know how to rename a file...:D

Cheers
manolito

LoRd_MuldeR

25th February 2012, 03:35

So if you have a music file with a title and/or artist that happens to not be representable in your local ANSI codepage, then you rename it to ... ?

And if the renamed file is transferred to another computer later and that computer happens to have a different ANSI codepage configured, so now the new name cannot be represented, you rename the file again?

And again... And again... But we are getting off-topic here ;)

VzK

25th February 2012, 03:56

LoRd_MuldeR

25th February 2012, 04:10

If I select up to 15 audio files in a folder and right-click, "Convert this file with LameXP v4.04" appears and the conversion runs just fine.
Anything more than that, and there is no bold option.
This would be a Windows "problem", right?

You mean that 'Convert this file with LameXP v4.04' appears in the Explorer context menu, if you select 15 files. But does not appear if you select even more files?

Do all these files have the same extension? I would understand this behavior, if some of the files have extensions that are associated with LameXP and some have other extensions.

In that case, the LameXP context menu entry would only appear if all files in your selection have an extension that is associated with LameXP.

Or in other words: Make sure that each file in your selection has the context menu entry individually. Only then the whole selection can have the context menu entry too...

VzK

25th February 2012, 04:18

They have all the same extension and they have all the context menu individually.

No LameXP (and MediaInfo - only noticed this now) option available when +15.

http://i.imgur.com/opF1L.png (http://imgur.com/opF1L)

LoRd_MuldeR

25th February 2012, 04:20

Hmm, then that's really strange. But as it happens with MediaInfo's context menu entry too, I don't think it's a LameXP issue.

But I can reproduce the issue here! Maybe Windows doesn't allow more 15 items, because launching the application more than 15 times might slow down the system too much.

I remember that in older versions of Windows there was a warning popup, asking if you really want to proceed, when you tried to select+open a lot of files this way...

VzK

25th February 2012, 05:02

Yeap, Windows limitation.
Found this (http://support.microsoft.com/kb/2022295/), works great, all files converted smoothly. :D

Vospi

25th February 2012, 13:05

You are the first one to report this problem. So what details does the log give for the "Not found!" items? :confused:

Do you have any Antivirus program with "real-time scanner" or "behavior scanner" or "guard" feature installed? If so, try to temporarily uninstall/disable it and see if that makes any difference.

Also: Is the problematic file located on some network drive or USB device? And does the problem still occur with LameXP v4.04 Beta-1 ???

(1) The problem was gone when I've disabled avast! antivirus.
(2) Before I've disabled avast!, it was almost the same with the latest beta (Build 892), but this time it was a diferent message that read "Failed!".
(3) The log for the problematic files was:

LameXP v4.04 (Build #892), compiled on 2012-02-23 at 21:17:24

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

C:/WINDOWS.0/TEMP/5453eb697217448fba059269ae2c6a3c/tool_flac.exe -d -F -f -o F:\temp\4073285ae87647ffb9c13a9ca9540f8a.wav "F:\Music\!dnb\Hospital Records\!flac\London Elektricity - Live At The Scala_FLAC\09 - London Elektricity - Main Ingredient.flac"

Exited with code: 0x0000

Adding LameXP to exceptions list did no good, so I'm supposed to reconvert failed files every time or to disable my antivirus while converting.

LoRd_MuldeR

25th February 2012, 13:55

(1) The problem was gone when I've disabled avast! antivirus.
(2) Before I've disabled avast!, it was almost the same with the latest beta (Build 892), but this time it was a diferent message that read "Failed!".
(3) The log for the problematic files was:

LameXP v4.04 (Build #892), compiled on 2012-02-23 at 21:17:24

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

C:/WINDOWS.0/TEMP/5453eb697217448fba059269ae2c6a3c/tool_flac.exe -d -F -f -o F:\temp\4073285ae87647ffb9c13a9ca9540f8a.wav "F:\Music\!dnb\Hospital Records\!flac\London Elektricity - Live At The Scala_FLAC\09 - London Elektricity - Main Ingredient.flac"

Exited with code: 0x0000

Adding LameXP to exceptions list did no good, so I'm supposed to reconvert failed files every time or to disable my antivirus while converting.

It's not the first time that an "anti-virus" software attacks a legitimate software :rolleyes:

You should report the problem to the support of your anti-virus software. And, if they don't fix the problem in time, switch to a better a/v solution!

There are various decent free solutions available. Personally I'm satisfied with MSE and/or Avira Antivir...

Yeap, Windows limitation.
Found this (http://support.microsoft.com/kb/2022295/), works great, all files converted smoothly. :D

Good finding. Will add this to the F.A.Q document.

LoRd_MuldeR

26th February 2012, 19:59

LameXP v4.04 Beta-3:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.2 Final (2011-11-18), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.134))
* Updated MediaInfo to v0.7.53 (2012-01-24), compiled with ICL 12.1.6 and MSVC 10.0
* Updated SoX to to v14.4.0 RC-3 (2012-02-20), compiled with ICL 12.1.7 and MSVC 10.0
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

This should fix the SoX normalization issue with some multi-channel sources when "-n" option is used.
Consequently the default normalization mode has been changed to "-n" again...

LoRd_MuldeR

2nd March 2012, 01:56

LameXP v4.04 Beta-4:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.53 (2012-01-24), compiled with ICL 12.1.6 and MSVC 10.0
* Updated SoX to to v14.4.0 RC-3 (2012-02-20), compiled with ICL 12.1.7 and MSVC 10.0
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

Note: This build fixes a regression (introduced in Beta-1) related to Job Object handling, which could cause encoder processes to be terminated prematurely.
Funnily enough, there was another problem that often broke Job Object handling on Vista (and later) and thus the former problem mostly didn't occur...

Chumbo

4th March 2012, 23:49

Just wanted to drop a note to say thank you for this tool. I needed to convert a bunch of flac files to mp3 so I can play them in my car and when I tried lame by itself it didn't recognize the flac source. So did a quick search for a tool and here it is. Worked great. Many thanks. BTW, if any chance at all, would love to see a CLI version. :)

LoRd_MuldeR

4th March 2012, 23:59

BTW, if any chance at all, would love to see a CLI version. :)

This is a GUI front-end for a bunch of CLI tools (LAME, OggEnc, FLAC, etc), so your request seems a bit paradoxical.

If you want to do batch encoding via CLI, e.g. from a batch script, then you can call the involved CLI tools directly and you don't need LameXP as another layer in between.

Anyway, LameXP does support a few command-line switches, e.g. for adding files or folders from the command-line. Probably not what you want though...

Chumbo

5th March 2012, 00:11

This is a GUI front-end for a bunch of CLI tools (LAME, OggEnc, FLAC, etc), so your request seems a bit paradoxical.

If you want to do batch encoding via CLI, e.g. from a batch script, then you can call the involved CLI tools directly and you don't need LameXP as another layer in between.

Anyway, LameXP does support a few command-line switches, e.g. for adding files or folders from the command-line. Probably not what you want though...
Yep, I just figured it's nice to have all the functionality in one place. Not a big deal. I actually could have used eac3to/lamexp to accomplish what I needed via CLI. ;) Thanks again.

devarni

6th March 2012, 00:18

There is some levelling data written also when the option is disabled. So coded MP3s have not 100% volume level when played with a player supporting this (like MediaMonkey).
Normally leveling data should be "0" when not enabled in the extended options

LoRd_MuldeR

6th March 2012, 00:20

What is "levelling data" :confused:

devarni

6th March 2012, 00:31

What is "levelling data" :confused:

Volume normalization.
With newer versions of LameXP there is some normalizing data in dB written, so players which support this will play the track not at 100% volume level. This data is written also when the options is disabled.
In MediaMonkey it will be displayed in the file properties details with "leveling: Track: -6dB"

LoRd_MuldeR

6th March 2012, 00:39

devarni

6th March 2012, 00:47

LameXP does support volume normalization, but it's completely optional.

Also normalization does not happen by writing any kind of "normalizing data" (whatever that is supposed to be) to the file.

Instead, if (and only if) normalization is enabled, the source is decompressed first and then the audio is normalized via SoX before it is sent to the encoder.

Again, this is optional and it is disabled by default (see the "Advanced Options" tab). Also I have no idea what kind of info "MediaMonkey" displays.

But something has changed with the latest versions. I tried a different frontend "Lame Front-End 1.7" and this works perfectly.
Is there eventually some kind of meta-data field where applications can store the computed normalization level in Decibel?

LoRd_MuldeR

6th March 2012, 00:51

But something has changed with the latest versions. I tried a different frontend "Lame Front-End 1.7" and this works perfectly.

Between which two builds exactly you think there is a difference?

Is there eventually some kind of meta-data field where applications can store the computed normalization level in Decibel?

If such thing exists, LameXP doesn't use it. AFAIK the LAME encoder will add "replay gain" tags by default though. LameXP does not induce this ;)

Also note that "replay gain" is just a hint, which can be used by the player to attenuate or amplify the signal, but it does not modify the audio stream at all.

If you are using a player with "replay gain" support and don't want the loudness to be equalized, you have to disable this "feature" in the individual player!

devarni

6th March 2012, 01:07

Between which two builds exactly you think there is a difference?
If such thing exists, LameXP doesn't use it.

I don't update all versions... the latest version must be early in 2011 where it works. If have some time I will install and test some older versions.

LoRd_MuldeR

6th March 2012, 01:23

I don't update all versions... the latest version must be early in 2011 where it works. If have some time I will install and test some older versions.

Well, there have been about ~600 revisions since then! However I am pretty sure that what you call "leveling data" is simply the "replay gain" tag that LAME will add automatically ;)

As explained before, ReplayGain-based loudness equalization is a "feature" of your individual player and thus has to be turned off in the player, if you don't like it.

See also:
http://en.wikipedia.org/wiki/Replay_Gain

devarni

6th March 2012, 09:42

Well, there have been about ~600 revisions since then! However I am pretty sure that what you call "leveling data" is simply the "replay gain" tag that LAME will add automatically ;)

As explained before, ReplayGain-based loudness equalization is a "feature" of your individual player and thus has to be turned off in the player, if you don't like it.

See also:
http://en.wikipedia.org/wiki/Replay_Gain

I think we get a bit closer... Lame seems to store replay gain informations per default (since newer version I guess).

"--noreplaygain
Disable ReplayGain analysis.
By default ReplayGain analysis is enabled. This switch disables it."

Is LameXP using "--noreplaygain" per default if the option is disabled in the LameXP settings?

[Edit]
I added the custom option --noreplaygain and now it's working... Eventually you should hardcode this switch so all is working as expected?

LoRd_MuldeR

6th March 2012, 13:56

LAME creates the "replay gain" tag automatically. LameXP does not tell LAME to create such tag, nor does it tell LAME to not create the tag.

I can't hardcode the "--noreplaygain" switch, because the users who want to use ReplayGain in their players rely on that tag. These users would not be able to use ReplayGain anymore!

At the same time, the presence of a "replay gain" tag does no harm for users who don't use ReplayGain. It's just a hint and it can safely be ignored...

(Again: If you don't like ReplayGain, simply disable that "feature" in your player. By not creating a ReplayGain tag, you intentionally "break" that feature rather than disabling it)

devarni

6th March 2012, 14:05

LAME creates the "replay gain" tag automatically. LameXP does not tell LAME to create such tag, nor does it tell LAME to not create the tag.

I can't hardcode the "--noreplaygain" switch, because the users who want to use ReplayGain in their players rely on that tag. These users would not be able to use ReplayGain anymore!

At the same time, the presence of a "replay gain" tag does no harm for users who don't use ReplayGain. It's just a hint and it can safely be ignored...

Hardcode means, you should add the option "--noreplaygain" in the "background" if the user has the option disabled (default setting) in the LameXP options. If the option is enabled than of course not.

Some applications using the "replaygain" tag and if set playing with a modified volume and this is not the wished behavior.

LoRd_MuldeR

6th March 2012, 14:18

Hardcode means, you should add the option "--noreplaygain" in the "background" if the user has the option disabled (default setting) in the LameXP options. If the option is enabled than of course not.

I won't add a GUI option to disable the generation of "replay gain" tags, because I don't want to encourage people to use such "exotic" (and potentially problematic) settings.

While having a "replay gain" tag certainly does no harm (it's just a hint, it does NOT effect the audio data at all), not having the tag breaks some functionality - functionality that is desired by many users!

Consequently the great majority of all users is better off with a "replay gain" tag. Actually I can't think of a reason to not store these tags, if LAME can add them "for free".

The few "power users" who really understand how ReplayGain works and who have a good reason to disable the generation of ReplayGain tags, can still add "--noreplaygain" to the custom LAME parameters.

The custom parameters box is intended exactly for this kind of exotic (rarely used) parameters.

Some applications using the "replaygain" tag and if set playing with a modified volume and this is not the wished behavior.

If the ReplayGain feature of the individual playback software is enabled, then equalizing the volume (or more precisely: the loudness) of different tracks is exactly the "wished" behavior.

If your "wished" behavior is to not apply ReplayGain (which is perfectly comprehensible), then don't use it. Disable that "feature" of your player. It's as simple as that :)

(Note: ReplayGain is a feature of your player. It's NOT a feature of the encoder. The encoder can only add the required tags, which enable the player to apply ReplayGain - optionally!)

LoRd_MuldeR

6th March 2012, 21:27

LameXP v4.04 Beta-5:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.53 (2012-01-24), compiled with ICL 12.1.6 and MSVC 10.0
* Updated SoX to to v14.4.0 RC-3 (2012-02-20), compiled with ICL 12.1.7 and MSVC 10.0
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

The QAAC Encoder Add-in for LameXP has been updated as well:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0

Taurus

9th March 2012, 17:03

LoRd_MuldeR

9th March 2012, 17:18

Just discovered the yellow message in the console output:
"Potential deadlock in initalization thread!"
This is on an old AMD Athlon XP mainly used for audio encoding.
Antivirus guard disabled.
Everything is working as expected, just a little curious.
And yes, I searched the thread and your FAQs (a little):p

This warning message was added recently, when I fixed a possible deadlock situation that could occur during the initialization of LameXP and probably existed since v4.00 ;)

Because the "main" thread is waiting for the "init" thread to finish its work, it is very important that the "init" thread eventually sends its finished message.

In very rare cases, however, it could happen that this finished message got lost, even before the "main" thread started waiting. It then would have waited for the message indefinitely!

As I have implemented a workaround now, this can not happen anymore. Additionally there will be a warning message now, if the "init" thread does not finish in due time.

Of course on a "slow" computer it can take "longer than usual" to finish and thus you may see the warning. You can safely ignore that, as long as LameXP does start up eventually...

Taurus

9th March 2012, 17:44

Thank you for your support.:thanks:

LoRd_MuldeR

10th March 2012, 15:55

LameXP v4.04 Beta-6:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.53 (2012-01-24), compiled with ICL 12.1.6 and MSVC 10.0
* Updated SoX to to v14.4.0 RC-3 (2012-02-20), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.5 (2011-03-07), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

manolito

11th March 2012, 03:59

More work for you: sox-14.4.0 has gone final

Cheers
manolito

LoRd_MuldeR

11th March 2012, 15:00

More work for you: sox-14.4.0 has gone final

Cheers
manolito

Doesn't look like there was any change since RC-3 that would effect us. But I will make a new build anyway...

KamikazeCJ

19th March 2012, 01:25

mariush

19th March 2012, 01:36

Don't do that.

Your CBR 320 audio file already went through a process where some details the encoder thinks you won't notice were cut out to get the bitrate to 320kbps.
When you compress it again to VBR, the encoder will use a different set of rules to determine what could be cut out without you noticing much, so you're always going to get a worse result.

It's like taking a picture, saving it to JPG at 90% quality, then saving it again at 75% quality - the result will look worse than taking the original and saving it directly to 75% quality.

Is it really worth losing quality, just to save about 300-500 KB out of 3-4 MB?

LoRd_MuldeR

19th March 2012, 01:40

Can someone please clear something up for me? I just started using this LAMEXP latest version. I have mp3 music files encoded @320CBR. I decided to re-encode the CBR to VBR in the interest of maintaining quality and shrinking file size. I'm using Highest quality bitrate settings (0) and the lame settings are the best quality. Everything else in advanced I'm leaving default (no bitrate management). Now I know a Lossy format to a Lossy format isn't the best encode but...
No matter if I go 320CBR to 320CBR or 320CBR to Highest quality VBR, my original file sounds louder than my ouput. Even clearer (and I don't think it's just because its louder). The volume norm. or tone adj. is not used in the encode.
Why this kinda dramatic change in sound? Don't get it.

First of all you should be aware that re-encoding from a lossy format to a lossy format, such as re-encoding from MP3 to MP3, will cause some "generation loss" for sure!

Secondly, with VBR mode "0" you will probably get a file that uses 320 kbps most of the time. So in order to get a "reasonable" file size reduction that justifies the re-encoding and still retain acceptable quality, I would try mode "2".

Last but not least: Something that has been discussed recently in this thread is that up-to-date LAME will automatically add "ReplayGain" tags to the encoded file (and some older version apparently did not).

So if your playback software supports ReplayGain and you have that feature enabled and to original 320 kbps CBR file happens to not have a "ReplayGain" tag, only the re-encoded file will be subject to ReplayGain at playback-time!

ReplayGain adjusts the volume (or more precisely the "loudness") of the file, in order to keep the same loudness across different files. This can be the reason that the new file is played back at a "lower volume" than the old one ;)

(And, as a well known fact, the human ear has a tendency to prefer the "louder" file in a quality comparison)

KamikazeCJ

19th March 2012, 04:50

Thanks for your responses. I get the generation loss thing.

Mariush, my thinking is this: The source files are recorded at 320CBR and when I went to VBR with 126 (roughly) music files, it took nearly 200mb (roughly) off the files. That's an extra 30-35 music files' worth of space. I was thinking there's a lot of "dead" space in 320cbr which would give me a little bit of allowance for the lossy to lossy encode. Just my thinking...

The replay gain tag, mulder, would seem like a culprit, I didn't know of it. Essentially, what your saying is that the source files may not of had that tag on them (cuz they were louder), and the re encode now has them and needs them to be read to make the file sound equivallent to the original. And they sound low because my player (media monkey) doesn't have replay gain enabled. Or am I still confused?
Original files were encoded with LAME3.98r and others were 3.98.4. How do I know if they were recorded with replay gain, Medainfo app doesn't seem to say. In addition is there a way to turn it offduring encode or is it better? I'll try to find more info about it.

KamikazeCJ

19th March 2012, 05:08

So, thinking about this and looking up replay gain, this tag justs helps "normalize" the volume of the tracks in relation to each other and lameencoder does that for you and passes the info on in the tag??? (assuming) More importantly just because the volume is different doesn't mean the quality of the file is worse than the original, just a lower volume. Right? (Of course other than the CBR to VBR re encode).
However I don't have volume normalization checked in LAME. Or did the original file have the tag on it with a loud bias and the re encode reverted it back to the original volume?

mariush

19th March 2012, 12:34

You can disable it if you use the command line encoder or if you encode the files to mp3 from a software that allows you to edit the parameters.

examples...

lame.exe -noreplaygain --preset insane file.wav file.mp3

will create file.mp3 out of file.wav , a 320kbps cbr file with minimal loss and no replay gain

lame.exe -noreplaygain --preset standard file.wav file.mp3

will create file.mp3 out of file.wav, a vbr file that will hover around 192kbps

If you want I can create a small script for you to batch convert the files, if you can't add the -noreplaygain parameter in lamexp

-

about the generation loss ... i guess it depends on the source of the files. If the files were generated straight from CD or from flac files... those 320kbps could very well be actual content, which your ears would notice if you have quality speakers. FLAC files (lossless audio are in general about 550-800 kbps, so there is information in audio files that gets cut down even at 320kbps - there's no reason an encoder would just fill up those 320kbps with junk.
When you get it down to 192kbps, something will be lost. If you can live with it, that's fine.

LoRd_MuldeR

19th March 2012, 12:55

So, thinking about this and looking up replay gain, this tag justs helps "normalize" the volume of the tracks in relation to each other and lameencoder does that for you and passes the info on in the tag??? (assuming)

The ReplayGain tag is just some "extra info" that is added to the MP3 file. It does not alter the audio data at all.

More importantly just because the volume is different doesn't mean the quality of the file is worse than the original, just a lower volume. Right? (Of course other than the CBR to VBR re encode).

As said before, the human ear has a tendency the rate a "louder" file with better quality, even when the files would sound identical at the same volume.

Thus a quality comparison needs to be done at the same "loudness" for all files. Otherwise the results are pretty much meaningless...

However I don't have volume normalization checked in LAME. Or did the original file have the tag on it with a loud bias and the re encode reverted it back to the original volume?

Adding the ReplayGain tag to the MP3 files does not apply any kind of volume normalization.

It just adds an additional info, which later can be used to apply "loudness adjustment" via ReplainGain. Though applying ReplainGain still is 100% optional!

Moreover, ReplainGain is a function of your playback software and you can disable it there, if you don't like it.

The ReplayGain tag is just a prerequisite for using ReplayGain at playback-time. It does not imply that ReplayGain will actually be used ;)

Or in other words: Don't have a ReplayGain tag -> can't use ReplayGain. Have a ReplayGain tag -> may use ReplayGain (if desired) or may ignore the tag.

Now if you have ReplayGain enabled in your playback software and one file has the required tag while the other files does not, then only the first one file will be "adjusted".

Of course, as soon as you disable the ReplayGain function of your playback software, no file will ever get "adjusted" by ReplayGain...

manolito

19th March 2012, 12:57

If you want I can create a small script for you to batch convert the files, if you can't add the -noreplaygain parameter in lamexp

Yes you can add the -noreplaygain in LameXP.

The few "power users" who really understand how ReplayGain works and who have a good reason to disable the generation of ReplayGain tags, can still add "--noreplaygain" to the custom LAME parameters.

The custom parameters box is intended exactly for this kind of exotic (rarely used) parameters.

Cheers
manolito

LoRd_MuldeR

19th March 2012, 13:06

Yes you can add the -noreplaygain in LameXP.

You can do that. But that's just a workaround to intentionally "break" the ReplayGain function of your playback software.

Instead, simply disable ReplayGain in your playback software, if you don't like it...

KamikazeCJ

19th March 2012, 19:53

Thanks for clearing all that up Mulder and Mariush.
Does this Replay tag try to "preserve" the original sound by adding voulme and EQ info to playback because the encode has some loss or is it essentially a "loudness" button which I would presume the playback software would only need?

BTW my original loudness difference in pre encode and encoded songs was because "level playback volume" was checked in media monkey's settings. Oherwise files sound same from 320CBR to 265 VBR (plus the generation loss). That filesize went from 9.5m to 7.88 (about 1/5th). I think that's a good compromise for me.
Now I hope my car's music box accepts VBR files!....

oh one more thing... any thoughts when Lamexp will import cds. Blink 182 cd just had data files, etc. on it. And I just noticed cda doesn't work and you recommend exact audio copy. Is Itunes inferior at this. It seems so because if I remember, I couldn't get the proper import setting I wanted last try.

LoRd_MuldeR

19th March 2012, 19:57

Thanks for clearing all that up Mulder and Mariush.
Does this Replay tag try to "preserve" the original sound by adding voulme and EQ info to playback because the encode has some loss or is it essentially a "loudness" button which I would presume the playback software would only need?

The ReplayGain tag does not "do" anything. It's just an additional meta info ("Peak signal amplitude") that may be used for future processing. It's no different from an "id3" tag. The audio data itself is not altered at all.

If ReplayGain processing is enabled in your playback software and if the required ReplayGain tag is present in the audio file, then the loudness will be "adjusted" to 89 dB SPL (Sound Pressure Level).

LoRd_MuldeR

19th March 2012, 20:13

oh one more thing... any thoughts when Lamexp will import cds. Blink 182 cd just had data files, etc. on it. And I just noticed cda doesn't work and you recommend exact audio copy. Is Itunes inferior at this. It seems so because if I remember, I couldn't get the proper import setting I wanted last try.

Audio CD's do not contain any files at all. They contain audio tracks, but no data track. So there is no file system and thus no files.

The ".cda" files you may find on an Audio CD in Windows Explorer are "dummy" files generated/emulated by Windows.

In order to "extract" the audio tracks from an Audio CD to Wave files, you will need to use some Ripping software. LameXP can' do that!

Accurately ripping Audio Tracks is not trivial to do and I don't want to re-invent the wheel. With EAC we have a very good and free solution.

If EAC could be controlled from the command-line, I could integrate it into LameXP. But, as far as I know, that's not supported by EAC :o

About iTunes: The only thing I can say is that personally I wouldn't infect my computer with a mess like iTunes or QuickTime...

KamikazeCJ

19th March 2012, 20:26

I wasn't implying that replay was doing anything other than adding an info tag. Just wanted to know what it added for the playback to read. Apologies for not being clear. Either way your answer on loudness adjustment cleared it up.
Oh and I agree wholeheartedly with your itunes statement. Unfortunately, its all some people know (or have been brainwashed to know (i.e. wife, kids). I would like to get that "controlling" software off my computer but then they would be lost without the Ipad/Ipod syncing thing.

LoRd_MuldeR

19th March 2012, 21:31

I wasn't implying that replay was doing anything other than adding an info tag. Just wanted to know what it added for the playback to read.

The "ReplainGain tag" actually is one field of the LAME header. You can find the exact specification here:
http://gabriel.mp3-tech.org/mp3infotag.html#replaygain

KamikazeCJ

21st March 2012, 17:47

LoRd_MuldeR

21st March 2012, 18:59

Now that I've tried EAC (Looks like a really good app), I have I would think would be a simple question but my searches are coming up with nothing. When I use the freedb to get the file properties, I can't figure out how to transfer it to my files (album, year, etc). Only the track name and artist are written. EAC's forum is a bit slow to respond so I was hoping one of you could give me an easy answer hear. Sorry if this post is off thread.

If you let EAC rip the Audio CD as a Cue Sheet (see also second part of my post), then all meta info will be included in the Cue Sheet file.

And LameXP can import that info from the Cue Sheet later...

Oh And can EAC use your front end to the LAME encoder, Mulder? I used a wildcard (*) to get it to read LAMEXP.exe ove LAME.EXE. But it doesn't seen to work. Do I need to separately install LAME by itself?

EAC cannot use LameXP.

You can extract the audio to individual Wave files with EAC and then convert these files with LameXP later.

Or you can extract the audio tracks as a single "big" Wave file + Cue Sheet and then import that Cue Sheet in LameXP - that's the preferred solution.

And of course you can make EAC use the LAME encoder to output MP3's directly. Then LameXP is not used/needed at all.

KamikazeCJ

21st March 2012, 19:30

I just worked it all out then I read your message. But you confirmed things and cleared up the cue sheet. When I synced Lame.exe up to EAC there were more options regarding compression, etc and it transfered the info to the mp3s.
It shows integrity to hear the developer say LAMEXP may not be needed in this case.:) Its all working for me now thanks to your help. Of course I love your app and will be using it for all existing ripped files that need converting.:thanks::thanks:

LoRd_MuldeR

22nd March 2012, 00:20

LameXP v4.04 Beta-7:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.54 (2012-03-13), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

LoRd_MuldeR

24th March 2012, 22:39

LameXP v4.04 Beta-8:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.54 (2012-03-13), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

LoRd_MuldeR

24th March 2012, 23:06

Just discovered the yellow message in the console output:
"Potential deadlock in initalization thread!"
This is on an old AMD Athlon XP mainly used for audio encoding.
Antivirus guard disabled.
Everything is working as expected, just a little curious.
And yes, I searched the thread and your FAQs (a little):p

Okay, today I found another issue that may mistakenly trigger this warning (plus an additional waiting period!) under certain rare(?) circumstances.

Strangely enough, this never occurred on my native machine or in any of my VMware-based VM's. I noticed it in my VirtualPC-based VM ("Windows XP mode") though ;)

Beta-8 contains a workaround for this specific problem. So in case this happened on your system, the warning should be gone and startup should be faster now.

(There still is a chance that the warning occurred legitimately on your system, in which case you will see no difference ^^)

Taurus

25th March 2012, 09:25

Thank you, My Lord :p:D !
This does it.
No more yellow marks and LameXP is starting much faster.
Really appreciated :thanks:

LoRd_MuldeR

25th March 2012, 13:31

Good to know :)

Actually this is a nice example of race conditions:

:: Main thread ::

M01 connect(thread, SIGNAL(finished()), loop, SLOT(quit()), Qt::QueuedConnection);
M02 connect(timer, SIGNAL(timeout()), loop, SLOT(quit()));
M03
M04 while(thread->isRunning())
M05 {
M06 loop->exec();
M07 if(thread->isRunning())
M08 {
M09 qWarning("Potential deadlock in initialization thread!");
M10 }
M11 }

:: Worker thread ::

T01 DoActualWork();
T02
T03 [...]
T04
T05 emit thr->finished();
T06
T07 [...]
T08
T09 d->running = false;
T10 d->finished = true;

While the 'main' thread is waiting for the 'worker' thread to finish its job, it will be hanging in the Event Loop at M06.
Now it can happen that T05 gets executed in the 'worker' thread and then control switches to the 'main' thread immediately, i.e. T09 and T10 have not executed yet!
Consequently we will exit from M06, as the 'finished' signal just has been emitted - and that signal is connected to the 'quit' slot of the event loop.
However in M07 and M04 the "thread->isRunning()" expression will still evaluate to TRUE. That is because T09 and T10 have not "updated" the corresponding status flags yet :rolleyes:
As the result, we will enter the wait loop once more! And, as the thread is not running anymore, only the "timeout" will eventually help us the exit from the event loop...

(Note that the "Worker thread" code listed above is from the Qt Framework, so I cannot change that portion!)

SirKiwi

26th March 2012, 01:33

I know it's been mentioned a few times in this thread, but I would love to see an "overwrite original file" option.

Also, I would love to see a way to input an output directory in plain text (i.e. typing out the directory or copy/pasting a directory path) instead of using the tree pane with the mouse.

Other than that, I love how the software runs instances in parallel for multiples encodes. Great job!

LoRd_MuldeR

26th March 2012, 15:07

I know it's been mentioned a few times in this thread, but I would love to see an "overwrite original file" option.

I still don't like the idea :scared:

Also, I would love to see a way to input an output directory in plain text (i.e. typing out the directory or copy/pasting a directory path) instead of using the tree pane with the mouse.

There is no "input" directory, as the input/source files may be located in various directories. Also I cannot change the "File Open" dialog, as it's a system dialog.

It may be possible to add an editbox for the "output" directory though. Will have to figure out a way to integrate this into the GUI...

LoRd_MuldeR

27th March 2012, 23:09

LameXP v4.04 Beta-10:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Added a button to modify the current output folder path in an edit box
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.54 (2012-03-13), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

mike20021969

28th March 2012, 10:15

Are we getting close to the next stable?
Thanks.

LoRd_MuldeR

29th March 2012, 00:10

Are we getting close to the next stable?
Thanks.

It's done when it's done :devil:

LoRd_MuldeR

30th March 2012, 23:26

LameXP v4.04 Beta-11:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Added a button to modify the current output folder path in an edit box
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.54 (2012-03-13), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Tweaked directory outline on "output folder" tab for improved performance (hopefully)
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

In one of my tests, the latest tweaks could reduce the number of file system operations that were needed to initialize the directory outline from more than 20,000 to about 3,500 (as measured by ProcessMonitor). The actual speed-up may not be as high as these numbers may indicate, because Windows itself seems to do some caching to speed-up these file system operations. Still there should be a decent speed-up. Feedback is welcome...

mike20021969

31st March 2012, 23:49

LameXP v4.05 has been released :)
The installer has certainly shrunk - 1.5MB compared with 15.8MB.
And the program launches ultra quick.

Didn't we used to be able to encode to mp4 using AAC?
I can only seem to do mp3 for some reason.

EDIT - I just noticed the changes. Oh well, back to the previous version for me.

Sorry, but 4.05 is a gigantic step backwards if ever there was.

Taurus

1st April 2012, 04:09

LameXP v4.05 has been released :)
Har,har,har, :goodpost::p;):D

lethedoom

1st April 2012, 04:32

LameXP v4.05 has been released :)
I nearly always need to encode flac files to mp3 and I value the import metadata feature added during 4,04 beta development. Since 4.04 beta license is time limited and no 4.04 final seems to have been offered ( 4.03 final-->4.04 betas -->4.05 final ) is my only option to revert to 4,03 final and use other applications to amend tags ?

Again, thank you for your generosity in providing this very useful free application for many years and valued tutelage.

best wishes for your efforts.

lethedoom

I just remembered today is already April 1 in your time zone--Is the de facto termination of the v 4.04 development process a joke ?

boyumeow

1st April 2012, 05:06

...
* Major codec clean-up: Dropped all encoders, except for LAME MP3 and Ogg Vorbis

Were U facing some problems or U are just re-writing LameXP? Anyway, do take good care of yourself.

P.S. Can U add 'Normalization' in the 'config' page, Thanks in advance.

mr soft

1st April 2012, 09:32

Har,har,har, :goodpost::p;):D

+1

got me too :o

cengizhan

1st April 2012, 20:31

That have you done? :scared: This version is 1st April joke.

boyumeow

2nd April 2012, 08:11

Bug report:

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

expiered! :sly:

Octo-puss

2nd April 2012, 08:41

Why did you drop all the encoders? Sounds like months of work wasted.

edit: that's what happens when I catch up on forums with delay. (and only read the first line on top of that lol)

LoRd_MuldeR

2nd April 2012, 16:06

Bug report:

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

expiered! :sly:

Typo will be fixed for next year's version ;)

LoRd_MuldeR

3rd April 2012, 22:03

LameXP v4.04 Beta-12:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Added a button to modify the current output folder path in an edit box
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.54 (2012-03-13), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Tweaked directory outline on "output folder" tab for improved performance (hopefully)
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

mr soft

4th April 2012, 08:22

Tweaked directory outline on "output folder" tab for improved performance (hopefully)

Thank you , output folder is now opening a lot faster. :D:D

LoRd_MuldeR

4th April 2012, 21:27

Thank you , output folder is now opening a lot faster. :D:D

Good to know :)

LoRd_MuldeR

6th April 2012, 02:12

LameXP v4.04 Beta-14:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2012-04-06/

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Added a button to modify the current output folder path in an edit box
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.54 (2012-03-13), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Tweaked directory outline on "output folder" tab for improved performance (hopefully)
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

manolito

9th April 2012, 19:36

The only thing I can say is that personally I wouldn't infect my computer with a mess like iTunes or QuickTime...
Totally agreed...:D
But according to the latest test results, QAAC seems to have an edge over Nero and even over FHG.
Do you know if there is a way (maybe some unofficial hack) to use QAAC without actually having to install QuickTime?

Cheers
manolito

LoRd_MuldeR

9th April 2012, 21:12

Totally agreed...:D
But according to the latest test results, QAAC seems to have an edge over Nero and even over FHG.
Do you know if there is a way (maybe some unofficial hack) to use QAAC without actually having to install QuickTime?

Cheers
manolito

In order to use QAAC, you need an "Apple Application Support" installation. You don't need QuickTime or iTunes, but AFAIK these are the only official downloads that include "Apple Application Support".

If you already have an installation of "Apple Application Support" on another system, you can copy over the files. But it won't be possible redistribute these files...

littleD

9th April 2012, 22:13

Do you know if there is a way (maybe some unofficial hack) to use QAAC without actually having to install QuickTime? Since forever iTunes instalation was selfexecutable archive. Just unpack it and u will get every program instalation separated. You may install Apple Application Support as standalone but dont ask me how to install QTime aac codec, i used iTunes two to three versions before. I bet there are some instructions over internet.

To install iTunes without QuickTime use bat file with code: msiexec.exe /i iTunes.msi /quiet . Old hacks always the best http://www.mydigitallife.info/download-and-install-itunes-without-quicktime/

LoRd_MuldeR

10th April 2012, 15:56

LameXP v4.04 Beta-15:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2012-04-10/

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Added a button to modify the current output folder path in an edit box
* Updated Qt runtime libraries to v4.8.0 (2011-12-15), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.56 (2012-04-08), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Tweaked directory outline on "output folder" tab for improved performance (hopefully)
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

LoRd_MuldeR

10th April 2012, 21:19

LameXP built with Qt 5.0 (http://labs.qt.nokia.com/2012/04/03/qt-5-alpha/) Alpha:

Warning: This could make your computer explode or may not work at all. Use at your own risk! :devil:

SeeMoreDigital

10th April 2012, 21:33

[B]LameXP built with
Warning: This could make your computer explode or may not work at all. Use at your own risk! :devil:
Cool... an exploding computer... I'm downloading and installing it right now!

LoRd_MuldeR

11th April 2012, 23:11

Here is a binary of LameXP that was built with static Qt 5.0 Alpha libraries:
http://www.mediafire.com/file/0nv4kofjczdbm4z/LameXP_Qt5.2012-04-11.Release.Build-971.7z

Warning: This could make your computer explode or may not work at all. Use at your own risk! :devil:

Przemek_Sperling

12th April 2012, 07:12

LameXP built with Qt 5.0 (http://labs.qt.nokia.com/2012/04/03/qt-5-alpha/) Alpha:

Warning: This could make your computer explode or may not work at all. Use at your own risk! :devil:

It resembles me AC/DC and "That's The Way I Wanna Rock'n'Roll":

"I'm gonna blow up my video
Shut down my radio...":devil:

Taurus

12th April 2012, 09:45

It did not explode :(:D

Some bugs/suggestions:

Remove floppy seek at first start.
The error message scared me a little :D.

Sometimes the GUI does not recover from the taskbar.
Rightclicking re-established it.

DCA encoder throws an error at bitrates below 256kbs (expected).

The dropbox does not work.

Speedwise I cannot say much. Did not do any benchmarking comparing standard LameXP -> Qt 5.0 Alpha

Anyway,:thanks::thanks:

LoRd_MuldeR

12th April 2012, 13:16

Some bugs/suggestions:

Remove floppy seek at first start.
The error message scared me a little :D.

:confused:

Sometimes the GUI does not recover from the taskbar.
Rightclicking re-established it.

The dropbox does not work.

Well, this is an "Alpha" release of Qt.

There are more issues I noticed:
* Icons in the TreeView/TableView don't show up
* Windows that should be "fixed size" can still be resized by the user
* The showEvent() is triggered twice, I already implemented a workaround
* Modal dialogs are not as modal as one would expect
* etc.

DCA encoder throws an error at bitrates below 256kbs (expected).

Probably not related to Qt at all.

Which bitrates work (or do not work) with DCAEnc seems to depend on the number of channels.

LoRd_MuldeR

12th April 2012, 16:39

LameXP v4.04 RC-1:

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for dcaenc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (see context-menu on the "Source Files" tab)
* Added a button to modify the current output folder path in an edit box
* Updated Qt runtime libraries to v4.8.1 (2012-03-14), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.56 (2012-04-08), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Tweaked directory outline on "output folder" tab for improved performance (hopefully)
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization code

Octo-puss

21st April 2012, 08:30

Feature request:
Please set sounds to DISABLED by default. Please!
edit: in fact, can't you get rid of those completely? This is not Windows where losers demand their speakers to play funky stuff when they click on stuff :P

Octo-puss

21st April 2012, 08:34

Taurus

21st April 2012, 09:56

Typo at cuesheet import:
Cuehseet Assistent :D

LoRd_MuldeR

21st April 2012, 12:27

Oh and btw something is wrong with the update feature. It reports build 986 being latest ( I have 972) but it's not on the web at all. I clicked through all the files there and latest change was 12.4. which is what I have. Huh? :confused:

If the Auto Update feature finds a newer version, it will offer to download the new version. So you don't have to download the new version from the web-site manually.

Also note: The latest version you can get via Auto Update is not necessarily identical to the latest version that is offered as a stand-alone download on the web-site!

edit: in fact, can't you get rid of those completely? This is not Windows where losers demand their speakers to play funky stuff when they click on stuff :P

No, I can't ;)

http://www.youtube.com/watch?v=hQ8tY0c-s04

LoRd_MuldeR

21st April 2012, 12:29

Typo at cuesheet import:
Cuehseet Assistent :D

Thanks for the report. Will fix (https://github.com/lordmulder/LameXP/commit/1bff20e6b9f9a69b68b97d7a4508421a5e915b75) that.

mike20021969

21st April 2012, 15:09

Should it not also be assistant?
<translation>Cuesheet Assistent</translation>

Octo-puss

21st April 2012, 15:50

If the Auto Update feature finds a newer version, it will offer to download the new version. So you don't have to download the new version from the web-site manually.

Also note: The latest version you can get via Auto Update is not necessarily identical to the latest version that is offered as a stand-alone download on the web-site!

Where does it get the new version from then?

I just don't use the auto update because it wants to install the program, which kills the purpose of downloading zip with just the files. Just make the files available on SF damnit :P

LoRd_MuldeR

21st April 2012, 16:13

Where does it get the new version from then?

From the update server. As you have noticed, the update server may provide a slightly newer version than SourceForge sometimes.

I just don't use the auto update because it wants to install the program, which kills the purpose of downloading zip with just the files.

The installer doesn't do any "fancy" things. It neither modifies your system nor collects any personal data. It basically extracts the required files to the "install" folder.

Also it is not possible to use the ZIP package for auto-update, because a running executable cannot replace itself. We need "somebody" to install the new files, after LameXP has exited.

That's why the auto-updater needs to use the installer. And the installer supports a special "update" mode for exactly that purpose ;)

Just make the files available on SF damnit :P

I urge you to remember rule #4.

Octo-puss

21st April 2012, 22:16

Update server NOT being part of SF clears it out, thanks.

Rule 4 of what where? I am confused.
edit: Huh, what profanity and not being nice? :-O Do you really read my post as being unfriendly/rude/whatever? I know this is the internets and you can't always tell how the posted meant it, but I thought it was pretty clear I was posting in a friendly way.

LoRd_MuldeR

21st April 2012, 22:37

Update server NOT being part of SF clears it out, thanks.

I prefer being in control of the update mirrors myself.

If something changes on the server that I have no control over, it may break the auto-update for all existing builds :scared:

edit: Huh, what profanity and not being nice? :-O Do you really read my post as being unfriendly/rude/whatever? I know this is the internets and you can't always tell how the posted meant it, but I thought it was pretty clear I was posting in a friendly way.

I quoted the part of your post that I was referring to. Also this was only a gentle reminder. No offense.

LoRd_MuldeR

26th April 2012, 15:31

LameXP v4.04 has been released :)

Changes between v4.03 and v4.04:
* Added support for the QAAC Encoder, requires QuickTime v7.7.1 or newer (see FAQ doc (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0) for details)
* Added Chinese and Taiwanese translations, thanks to 456Vv <123@456vv.com>
* Added experimental support for DCA Enc, created by Alexander E. Patrakov <patrakov@gmail.com>
* Added CSV export/import for Meta tags (available from the context-menu on the "Source Files" tab)
* Added a button to modify the current output folder path in an edit box
* Updated Qt runtime libraries to v4.8.1 (2012-03-14), compiled with MSVC 10.0
* Updated LAME encoder to v3.99.5 Final (2012-02-28), compiled with ICL 12.1.7 and MSVC 10.0 (details (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.139))
* Updated MediaInfo to v0.7.56 (2012-04-08), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.0 (2012-03-04), compiled with ICL 12.1.7 and MSVC 10.0
* Updated mpg123 decoder to v1.13.6 (2011-03-11), compiled with GCC 4.6.1
* Updated Monkey's Audio binary to v4.11 (2011-04-20)
* Updated Musepack decoder to revision 475 (2011-08-10), compiled with ICL 12.1.6 and MSVC 10.0
* Updated GnuPG to v1.4.12, compiled with GCC 4.6.1
* Updated language files (big thank-you to all contributors !!!)
* Implemented coalescing of update signals to reduce the CPU usage of the LameXP process (details (http://forum.doom9.org/showpost.php?p=1539631&postcount=507))
* Run more than four instances in parallel on systems with more than four CPU cores (details (http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#89cbd3d0))
* Improved handling of different character encodings for Playlist and Cue Sheet import
* Tweaked directory outline on "output folder" tab for improved performance (hopefully)
* Improved LameXP inter-process communication by adding queue support
* Workaround for a bug that causes MediaInfo to not detect the duration of Wave files (64-Bit only)
* Prevent LameXP from blocking a system shutdown (encoding process is aborted, if necessary)
* Improved internal handling of MediaInfo output, including extraction of cover art
* Fixed a very rare "live-lock" situation in early initialization codehttp://www.millan.net/minimations/smileys/hapydancsmil.gif

Przemek_Sperling

26th April 2012, 15:34

Well done! Thank you very much for your hard work! :thanks:

SeeMoreDigital

26th April 2012, 16:30

Hey, hey, hey... Great work mate ;)

Taurus

26th April 2012, 19:21

:goodpost::thanks:

Thank you!

pururin

28th April 2012, 19:52

4.04 Cool :D

Few questions : Do I need to use Lamexp's specific qaac addin or can I replace qaac file to newer version?

If not, how do I track the addin update easily?

qaac quality scale seems a bit confuse to me. I suppose q 0.75 in the gui is around tvbr Q90?
(Actually there're only 15 steps, why would Apple makes it Q0-127 :confused:)

LoRd_MuldeR

29th April 2012, 15:49

Few questions : Do I need to use Lamexp's specific qaac addin or can I replace qaac file to newer version?

Should be possible, unless the new version has changed the interface in a way that breaks compatibility.

If not, how do I track the addin update easily?

I will update the add-in as needed.

qaac quality scale seems a bit confuse to me. I suppose q 0.75 in the gui is around tvbr Q90?

The quality scale for VBR mode in the GUI is 0.00 to 1.00.

As LameXP supports various AAC encoders, LameXP will map the 0.00-1.00 scale to the "internal" representation of the individual encoder.

For the QAAC encoder the internal scale (as least the one that is exposed to the calling application) is 0-127, LameXP cannot do anything about that.

Consequently the 0.00-1.00 scale will be mapped to 0-127 by LameXP.

(Actually there're only 15 steps, why would Apple makes it Q0-127 :confused:)

Ask them :p

(They probably thought that making the quality scale a 7-Bit value should be sufficiently fine-grained for all future versions, even if the current version has fewer quality steps)

pururin

29th April 2012, 21:15

Thanks you Lord. :)

Dogway

1st May 2012, 15:34

LameXP v4.04 (Build #988), compiled on 2012-04-26 at 13:23:48

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

C:/DOCUME~1/ADMINI~1/CONFIG~1/Temp/34ed0c6bfc8349aaae62a81420ce853e/lamexp_valdec.exe "C:\audio_track.ac3" ↩
-w D:\Temp\812dfc4c29c1443d9ddbb1caa2659822.wav

Opening audio output PCM16 3/2.1 (5.1) 48000...
---------------------------------------
Streams found: 2
Frames/errors: 263716/0
System time: 221187ms
Process time: 129343ms
Approx. 1.53% realtime CPU usage

Exited with code: 0x0000

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

C:/DOCUME~1/ADMINI~1/CONFIG~1/Temp/34ed0c6bfc8349aaae62a81420ce853e/lamexp_sox.exe ↩
--i D:/Temp/812dfc4c29c1443d9ddbb1caa2659822.wav

C:\DOCUME~1\ADMINI~1\CONFIG~1\Temp\34ed0c6bfc8349aaae62a81420ce853e\lamexp_sox.exe FAIL formats: ↩
can't open input file `D:/Temp/812dfc4c29c1443d9ddbb1caa2659822.wav': WAVE: RIFF header not found

Exited with code: 0x0001

I'm trying to encode a 5.1 file using avs input.

My script plays fine in mpc:
l=WAVSource("l.wav")
r=WAVSource("r.wav")
c=WAVSource("c.wav")
lfe=WAVSource("lfe.wav")
ls=WAVSource("ls.wav")
rs=WAVSource("rs.wav")

MergeChannels(l,r,c,lfe,ls,rs)

Lame-xp fails with this error massage:
LameXP v4.02 (Build #578), compiled at 2011-06-14

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

C:/Users/NAUTIL~1/AppData/Local/Temp/d2d906dac226430bb5d0fee4458f206d/tool_avs2wav.exe ↩
C:\sintel\sintel-master-51-flac\51.master.avs ↩
C:\Users\NAUTIL~1\AppData\Local\Temp\d2d906dac226430bb5d0fee4458f206d\e36981fe6dde42c2bb51452c114e12c5.wav

avs2wav v1.2 [May 24 2011]
by Jory Stone <jcsston@toughguy.net>, updates by LoRd_MuldeR <mulder2@gmx.de>
Input: C:\sintel\sintel-master-51-flac\51.master.avs
Output: C:\Users\NAUTIL~1\AppData\Local\Temp\d2d906dac226430bb5d0fee4458f206d\e36981fe6dde42c2bb51452c114e12c5.wav
Checking Avisynth...
Done
Analyzing input file...
Done
Opening output file... Done
[Audio Info]
TotalSamples: 42624000
TotalSeconds: 888
SamplesPerSec: 48000
BitsPerSample: 16
Channels: 6
AvgBytesPerSec: 576000
Dumping audio data, please wait:
AVIStreamRead succeeded, but did not return any samples!
Failed to dump audio stream (status -4). Terminating!

Exited with code: 0xFFFFFFFC

Same here...
and Comodo Firewall doesn't let me set LameXP as a trust program from the pop up notifier, this is always an option when using programs.

more funny facts:
encoding a wav file requires decoding the wav :confused:
that translates to-> a 3Gb audio wav file from a 2h movie is instantly duplicated in the temporal folder, and if you use normalization or any other post filter, there will be a third instance of the file, that is almost 10Gb reading/writting to HDD and required free space.

LoRd_MuldeR

1st May 2012, 17:52

LameXP v4.04 (Build #988), compiled on 2012-04-26 at 13:23:48

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

C:/DOCUME~1/ADMINI~1/CONFIG~1/Temp/34ed0c6bfc8349aaae62a81420ce853e/lamexp_valdec.exe "C:\audio_track.ac3" ↩
-w D:\Temp\812dfc4c29c1443d9ddbb1caa2659822.wav

Opening audio output PCM16 3/2.1 (5.1) 48000...
---------------------------------------
Streams found: 2
Frames/errors: 263716/0
System time: 221187ms
Process time: 129343ms
Approx. 1.53% realtime CPU usage

Exited with code: 0x0000

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

C:/DOCUME~1/ADMINI~1/CONFIG~1/Temp/34ed0c6bfc8349aaae62a81420ce853e/lamexp_sox.exe ↩
--i D:/Temp/812dfc4c29c1443d9ddbb1caa2659822.wav

C:\DOCUME~1\ADMINI~1\CONFIG~1\Temp\34ed0c6bfc8349aaae62a81420ce853e\lamexp_sox.exe FAIL formats: ↩
can't open input file `D:/Temp/812dfc4c29c1443d9ddbb1caa2659822.wav': WAVE: RIFF header not found

Exited with code: 0x0001

Looks like either Valdec produced an invalid output Wave file or SoX didn't like the Wave file produced by Valdec for whatever reason.

Can you provide an AC-3 file to reproduce?

I'm trying to encode a 5.1 file using avs input.

My script plays fine in mpc:
l=WAVSource("l.wav")
r=WAVSource("r.wav")
c=WAVSource("c.wav")
lfe=WAVSource("lfe.wav")
ls=WAVSource("ls.wav")
rs=WAVSource("rs.wav")

MergeChannels(l,r,c,lfe,ls,rs)

Lame-xp fails with this error massage:
LameXP v4.02 (Build #578), compiled at 2011-06-14

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

C:/Users/NAUTIL~1/AppData/Local/Temp/d2d906dac226430bb5d0fee4458f206d/tool_avs2wav.exe ↩
C:\sintel\sintel-master-51-flac\51.master.avs ↩
C:\Users\NAUTIL~1\AppData\Local\Temp\d2d906dac226430bb5d0fee4458f206d\e36981fe6dde42c2bb51452c114e12c5.wav

avs2wav v1.2 [May 24 2011]
by Jory Stone <jcsston@toughguy.net>, updates by LoRd_MuldeR <mulder2@gmx.de>
Input: C:\sintel\sintel-master-51-flac\51.master.avs
Output: C:\Users\NAUTIL~1\AppData\Local\Temp\d2d906dac226430bb5d0fee4458f206d\e36981fe6dde42c2bb51452c114e12c5.wav
Checking Avisynth...
Done
Analyzing input file...
Done
Opening output file... Done
[Audio Info]
TotalSamples: 42624000
TotalSeconds: 888
SamplesPerSec: 48000
BitsPerSample: 16
Channels: 6
AvgBytesPerSec: 576000
Dumping audio data, please wait:
AVIStreamRead succeeded, but did not return any samples!
Failed to dump audio stream (status -4). Terminating!

Exited with code: 0xFFFFFFFC
Same here...

Well, there is not much I can do on my side, if AVIStreamRead() returns a code that indicates "success" but the number of samples returned is zero.

...except for reporting the "contradictory" state that has been encountered to the user ;)

and Comodo Firewall doesn't let me set LameXP as a trust program from the pop up notifier, this is always an option when using programs.

Well, I would recommend to send a bug report to Comodo, if the "white-list" doesn't work as expected.

more funny facts:
encoding a wav file requires decoding the wav :confused:
that translates to-> a 3Gb audio wav file from a 2h movie is instantly duplicated in the temporal folder, and if you use normalization or any other post filter, there will be a third instance of the file, that is almost 10Gb reading/writting to HDD and required free space.

Depending on what exactly you are doing, a temporary "working copy" needs to be created, even if both the, source file and the output file, are Wave files.

For example this will be necessary, if any filters are applied...

Dogway

1st May 2012, 18:48

Looks like either Valdec produced an invalid output Wave file or SoX didn't like the Wave file produced by Valdec for whatever reason.

Can you provide an AC-3 file to reproduce?
I tested the sample (cut ac3) file I was going to send you and it worked so I don't think it could be worth... but if you mind, the produced (intended) file was a 3Gb wav, there might be some hint...

Well, there is not much I can do on my side, if AVIStreamRead() returns a code that indicates "success" but the number of samples returned is zero.

...except for reporting the "contradictory" state that has been encountered to the user ;)
I don't know about that, I just wonder if avs processing has ever worked or not.

Well, I would recommend to send a bug report to Comodo, if the "white-list" doesn't work as expected.
I don't think Comodo keeps track of all the hobbyist applications I install (I doubt), but yours is the only one that didn't offer the option to "trust application". In this regard I think it has more to do with some nature of the program rather than Comodo white-listing, I still can go to Comodo options and manual white list LameXP, doable but a bit annoying. Just letting you know some curiosities of LameXP.

Depending on what exactly you are doing, a temporary "working copy" needs to be created, even if both the, source file and the output file, are Wave files.

For example this will be necessary, if any filters are applied...
Despite I still don't understand why a full copy of the file needs to be done (megui didn't do, behappy doesn't either if I'm not wrong...) what I refer here is that in the decoding stage of the wave file an exact wave file copy is done, this is before any filtering, just decoding, then a second copy is performed for the filtering dummy (normalisation, whatever).

http://i212.photobucket.com/albums/cc35/Dogway/Misc/LameXP-Temps.png

LoRd_MuldeR

1st May 2012, 19:10

I tested the sample (cut ac3) file I was going to send you and it worked so I don't think it could be worth... but if you mind, the produced (intended) file was a 3Gb wav, there might be some hint...

I think I know what the problem is:

Wave files (and RIFF files in general) can't grow lager than 4 GB. The limit might even be 2 GB, if the application interprets the chunk "size" field as signed.

There is some confusion about how the "size" field has to be interpreted, but more than 4 GB will never be possible with Wave files. There is no easy workaround for this restriction.

I think Valdec will create a RF64 (http://en.wikipedia.org/wiki/RF64) file rather than a Wave/RIFF file, if the size becomes too large. And it seems that SoX doesn't support RF64 files. The same applies to most tools!

(The only real solution would be switching to "RF64" as the common intermediate format. But as long as most of the audio tools don't support RF64, this is a lost case)

I don't know about that, I just wonder if avs processing has ever worked or not.

My avs2wav tool, based on the tool by Jory Stone, does work for me - most of the time. There only seem to be certain configuration that trigger the strange error.

I don't know why this happens. Actually I don't think this is supposed to happen at all...

I don't think Comodo keeps track of all the hobbyist applications I install (I doubt), but yours is the only one that didn't offer the option to "trust application". In this regard I think it has more to do with some nature of the program rather than Comodo white-listing, I still can go to Comodo options and manual white list LameXP, doable but a bit annoying. Just letting you know some curiosities of LameXP.

Maybe Comodo isn't prepared for the fact that LameXP is a front-end application and will launch other programs in the background.

There is no workaround, because this is "by design". Only way would be adding an option to Comodo that allows whitelisting a program and all child-processes it will create.

Despite I still don't understand why a full copy of the file needs to be done (megui didn't do, behappy doesn't either if I'm not wrong...) what I refer here is that in the decoding stage of the wave file an exact wave file copy is done, this is before any filtering, just decoding, then a second copy is performed for the filtering dummy (normalisation, whatever).

The processing steps in LameXP are as follows:
Decode source file to temporary Wave file > apply all filters on the temporary Wave file > encode temporary Wave file to final output

Actually there is a "shortcut" implemented in LameXP:
We can skip creating a temporary Wave file, if (and only if) the selected encoder can read/decode the individual source file directly.

This "shortcut" cannot be use if any filters are applied, for obvious reasons...

manolito

2nd May 2012, 22:08

I think Valdec will create a RF64 file rather than a Wave/RIFF file, if the size becomes too large. And it seems that SoX doesn't support RF64 files. The same applies to most tools!

(The only real solution would be switching to "RF64" as the common intermediate format. But as long as most of the audio tools don't support RF64, this is a lost case)

I made a few tests trying to reproduce Dogway's problem, and it is absolutely clear that SoX cannot use large WAV files above 4GB. When I used an older version of ValDec which does not support the WavFile_Extensible format Sox would not crap out with an error, but would instead cut off the source file after 15 minutes. Hopeless...

But if the desired target format is something other than Wav then any BeSweet based app can do this because no intermediate Wav file is used. I tried to convert a 6-ch AC3 file (duration almost 3 hours) to a 6-ch normalized AAC file, and BeLight had no problems with this conversion. (HeadAC3he could not do it, it would hang two thirds into the conversion)

Cheers
manolito

LoRd_MuldeR

2nd May 2012, 22:22

I made a few tests trying to reproduce Dogway's problem, and it is absolutely clear that SoX cannot use large WAV files above 4GB. When I used an older version of ValDec which does not support the WavFile_Extensible format Sox would not crap out with an error, but would instead cut off the source file after 15 minutes. Hopeless...

As explained before, Wave files cannot grow larger than 4 GB. That's an inherent limitation of the Wave/RIFF format.

If you ever see a Wave file that is larger than 4 GB, then this is either a RF64 file with a "wrong" file extension or it's a non-standard Wave file.

The former is isn't widely supported yet, the latter is predestinated to cause all kinds of problems...

But if the desired target format is something other than Wav then any BeSweet based app can do this because no intermediate Wav file is used. I tried to convert a 6-ch AC3 file (duration almost 3 hours) to a 6-ch normalized AAC file, and BeLight had no problems with this conversion. (HeadAC3he could not do it, it would hang two thirds into the conversion)

Well, if you don't create an intermediate Wave file, then of course you don't have to worry about the file size limit of Wave files.

manolito

2nd May 2012, 22:43

Well, if you don't create an intermediate Wave file, then of course you don't have to worry about the file size limit of Wave files.
Which leads me to the question if LameXP really should depend on intermediate Wave files for filtering. I am perfectly aware of the fact that this is the core design of LameXP in order to achieve maximum flexibility, but for a practical minded person like me the main objective is always "Does it work?" If not, I need to change the design... Oops, getting a little philosophical here :o

Cheers
manolito

LoRd_MuldeR

2nd May 2012, 22:59

Using Wave files as the intermediate format is the most flexible and most compatible solution, because all CLI decoders that I am aware of at least can write a Wave file and all CLI encoders at least can read from a Wave file. It seems Wave files are the "lowest common denominator" for audio tools. If we don't want to use intermediate files, then we need to pass the uncompressed data via pipe. Even if we assume all decoders can write to STDOUT and all encoders can read from STDIN, which in reality is not the case, what is the format we send over the pipe? Do we send "raw" PCM samples? Or do we send send some kind of "fake" Wave header? If we send "raw" samples, how to indicate the sample format and the number of channels? And how to indicate the total number of samples, so that the encoder can report progress? Will using a pipe work with 2-Pass filters in SoX? After all this will introduce more new problems than it solves, I think...

(And this doesn't even take into account the immense amount of work that would be required to re-write everything ^^)

Paddy97

4th May 2012, 19:49

Is there a way to make LameXP transfer the embedded cover art in a flac file when converting to AAC/MP3?

LoRd_MuldeR

4th May 2012, 19:55

Should be possible, yes.

Paddy97

4th May 2012, 20:02

Should be possible, yes.

Guessed so :-) On closer inspection its working for me if I use MP3 as output but not AAC using QT.

LoRd_MuldeR

4th May 2012, 20:20

Guessed so :-) On closer inspection its working for me if I use MP3 as output but not AAC using QT.

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)

manolito

4th May 2012, 23:11

(The only real solution would be switching to "RF64" as the common intermediate format. But as long as most of the audio tools don't support RF64, this is a lost case)
And it looks like this is not gonna happen anytime soon.

I found a request for SoX to support RF64 plus the answer from Chris Bagwell (it is from 2006), and it does not sound encouraging:
Chris Bagwell | 31 Mar 03:02
Re: New file format? (RF64)
It would be nice to at least see the WAVE64 portion to be rolled into
the current WAV handler. I've seen several requests for > 4gig audio
files in WAV format.

It should be simple enough to add support for both WAVE64 and RF64 since
the code to parse chunks already exists in the wav.c. Just need to
tweak it some to work with these other formats. I'll have to leave that
as an exercise for someone else though.

Chris

Which brings us back to the hard sad facts:

Unless LameXP changes its design fundamentally, it does (and will) not support multichannel source files with a duration of more than 2 hours.

For a 6-ch AC3 source file (16bits, 48 kHz) the threshold is at 2 hours 4 minutes. Audio files which are longer than this are quite common these days. This really limits the usefulness of LameXP.

Cheers
manolito

LoRd_MuldeR

4th May 2012, 23:50

Well, unless there is a feasible solution to overcome for the 4 GB limit (i.e. a solution that works with all decoders, with all encoders, with all filters and that can be implemented with acceptable effort) there isn't much I can do ;)

Paddy97

5th May 2012, 07:58

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)

It was this study that intrigued me from the beginning to start converting to AAC with QT instead of Nero.

http://listening-tests.hydrogenaudio.org/igorc/aac-96-a/results.html

Przemek_Sperling

13th May 2012, 14:30

Is any chance that LameXP will use the Fraunhofer AAC dll library (used by Winamp) with the aacPlus wrapper?

LoRd_MuldeR

13th May 2012, 14:32

Is any chance that LameXP will use the Fraunhofer AAC dll library (used by Winamp) with the aacPlus wrapper?

Please refer to the FAQ document:
http://lamexp.git.sourceforge.net/git/gitweb.cgi?p=lamexp/lamexp;a=blob_plain;f=doc/FAQ.html;hb=HEAD#71a113b0

Przemek_Sperling

13th May 2012, 17:37

Wow! Thanks a lot! Shame on me - I should check it more before I asked you.

LoRd_MuldeR

15th May 2012, 21:58

Here is a TEST build with the new multi-threaded file analyzer:
http://www.mediafire.com/file/0l8o6uqv6fvvll2/LameXP.2012-05-15.Release-Static.Build-1027.zip

This should make adding a huge number of input files quite a bit faster. Hopefully it doesn't break too many things ;)

(Also fixed a potential crash, when adding a lot of files. Successfully imported ~8000 audio files today)

Przemek_Sperling

19th May 2012, 11:31

I would like to let you know that QAAC and mp3tag do not work very well together. I know that LameXP has nothing to do with it, but I just want to let everybody know. Actually I have tried every possible combination of both (QAAC 1.35 and 1.36, mp3tag 2.50 and 2.51) and every third, forth or so album shows errors in tagging. Tag&Rename worls very well with the codec. Nero and FhG are do not make any problems with mp3tag, only the above combination of QAAC AND mp3tag. I already informed Florian Heidenreich (the creator of mp3tag) about the bug, but no answer yet. I just let you know, because detecting what is wrong took me some time, and I do not want the bug would put on anybody's nerves.

malch

24th May 2012, 04:29

I love LameXP and have been using it for years. Thanks for a wonderful tool.

However, the integrated updater drives me nuts. It creates/executes the file: $TEMP\random_string\lamexp_wget.exe. That's a real problem for those of us who use a software firewall to control outbound connections. The random_string element of the pathname means we cannot whitelist the updater because the pathname changes from one invocation to the next.

Could we have a static pathname for the updater, pretty please?

LoRd_MuldeR

24th May 2012, 12:30

However, the integrated updater drives me nuts. It creates/executes the file: $TEMP\random_string\lamexp_wget.exe. That's a real problem for those of us who use a software firewall to control outbound connections. The random_string element of the pathname means we cannot whitelist the updater because the pathname changes from one invocation to the next.

First of all, installing a software firewall is mostly pointless. All "incoming" connections are blocked by the broadband router anyway, unless you explicitly add a port-forwarding (virtual server) rule. A software firewall may be able to block "outgoing" connections. But as the software that would open these "outgoing" connections is running on your local computer, just as the software firewall does, circumventing the software firewall is quite easily for a malicious application. So if you don't trust a specific software, then simply don't install it on your local computer. And if you do trust it, then just let it do its job. If you want to "sandbox" a suspicious application, a VM is more suitable.

Having said that, for what a software firewall can do, the built-in "Windows Firewall" does a decent job. Consequently there are very few reasons to replace the Windows firewall with a third-party solution. Of course the developers of these third-party firewalls need to give their customers a reason to switch. They need to remind their customers that their firewall software is doing something for the customer's protection. And they need to do this regularly. That's why these firewalls tend to react overly nervous and stubborn. After all you will end up adding zillions of exception rules to shut up the firewall messages, destroying pretty much all the extra protection...

Could we have a static pathname for the updater, pretty please?

Sorry, I'm not going to change the design of LameXP, just because some software firewall is going nuts. I think a firewall shall protect the computer from unwanted connections. It shall NOT prevent wanted software from doing its job. And it certainly should NOT try to force a specif software design on thrid-party applications. A software firewall that interferes with legitimate software doing legitimate things is disqualifying itself.

BTW: If your software firewall doesn't allow you to specify a rule for "unblocking" Wget independent of the executable's fully-qualified path, then you should probably buy a book for first semester computer science students and send it to the developers of that firewall software. They might find the chapters about "regular expressions" and "hash functions" quite interesting...

malch

24th May 2012, 22:34

First of all, installing a software firewall is mostly pointless.

Sorry, I'm not going to change the design of LameXP, just because some software firewall is going nuts.

Okay, I respect your decision even if I do disagree with your views on firewalls.

A software firewall is, in my view, a very effective anti-malware tool that involves a fraction of the system overhead imposed by the commercial AV programs that most people run.

And yes, it would be very simple to use RegExp matching for whitelisted programs. That would however defeat the purpose since of the firewall because malware would (indeed already does) attempt to disguise itself by using filenames that match the names of legitimate executables but installing itself in a different folder.

Finally, the software firewall that I happen to use does not replace the standard Windows firewall. It simply extends the existing capabilities of the Windows firewall via the MS documented API's.

LoRd_MuldeR

24th May 2012, 23:01

And yes, it would be very simple to use RegExp matching for whitelisted programs. That would however defeat the purpose since of the firewall because malware would (indeed already does) attempt to disguise itself by using filenames that match the names of legitimate executables but installing itself in a different folder.

Well, if the "malware" is at the point where it can install itself to an arbitrary location on your system, it may as well disable/reconfigure the software firewall to not get into its way. Also a software firewall can be bypassed in various ways by a malicious application, e.g. by calling a "trusted" application (e.g. your web-browser) in the background and let it do the communication for you. Furthermore I doubt any malware would try to hide itself as "lamexp_something.exe" - it would rather pick a popular application that is more likely to be installed on the machine. But if a RegExp-based exception rule isn't feasible, you may still use a Hash-based one. The included Wget binary is rarely updated, so the Hash won't change...

LoRd_MuldeR

25th May 2012, 00:15

LameXP v4.05 Alpha-3

Changes between v4.04 and v4.05:
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated mpg123 decoder to v1.14.2 (2012-05-12), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.57 (2012-05-02), compiled with ICL 12.1.7 and MSVC 10.0
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files

VzK

29th May 2012, 02:35

A problem appeared using v4.05 Alpha-3 build 1030.

When using Cue Sheet Importer, if cue filename ends with an ellipsis (...), an error message appears:
http://i.imgur.com/uyJWm.jpg

This happens often, I just have to click OK and then Browse and Select; but this time when I click Browse the program hangs and I'm forced to give it the three-finger salute.

LoRd_MuldeR

29th May 2012, 09:35

Okay, I see what the problem is here:

A folder or file name must not end with a . character. Thus a folder of such name cannot be created and we will have a problem :eek:

This problem is not specific to v4.05 though. Probably exists ever since the CueSheet importer was added...

LoRd_MuldeR

29th May 2012, 20:48

LameXP v4.05 Alpha-4

Changes between v4.04 and v4.05:
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated mpg123 decoder to v1.14.2 (2012-05-12), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.57 (2012-05-02), compiled with ICL 12.1.7 and MSVC 10.0
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files
* Fixed a problem with Cue Sheet import and files that contain trailing dots in their name

Przemek_Sperling

30th May 2012, 05:46

I found an interesting review of LameXP yesterday http://www.addictivetips.com/windows-tips/lamexp-audio-encoder-highly-powerful-feature-rich-audio-converter/ A bit brief but shows pretty well what LameXP can do.

Kadai

19th June 2012, 21:21

First of all, thank you for this very nice piece of software. I totally love it (on windows).

Yet, it has some bugs and stuff that can help a lot to improve it. I have seen all of them on Windows 7 64bits.

Not sure if someone have already reported this, but when you are about to split a cuesheet, and the created folder has the same name than a file on the folder, LameXP is unable to create the folder (So far I know, this may be an issue of the system itself), there is a way to detect this collition on LameXP and prevent this? (appending something to the name of the folder, for example).

Also, Other things I have noticed is that LameXP "discards" tracks when they have a name "too long". This have happened me with some japanese albums that have "long names". You have to manually rename folders and try again in order to get the ommited tracks included the next time. A bit annoyning, but not so really an issue of LameXP, but detecting this too might be nice.

Continuing with the topic, but this time talking about cue sheets in general... There is a way to prevent to loss the already added splitted tracks?
Let's say that you had a LameXP crash while trying to add a cue sheet, but you had added previously other cues to the convertion queue. All of them get lost after that. While it is not a big deal when you have splitted only an album... it can be annoyning if you had 20 or more getting ready to be transcoded... because you have to split them all again (to keep the metadata), so far I know.

And of course, the last one is also related to the cuesheets. There is a way to "batch add" cueshets? Like we do with regular files? Havng the splitter is wonderfull, but maybe the dropzone might also work as a detection zone (if a cue sheet is dropped there) and try to "split" the cue in the bagground and add the resulting files to the queue. But this will be a plus.

Other things I have found are related to the tags of th encoded files. For example, if the file has a "Composer" tag, it is not copied to the newy encoded file. That happens not only to that tag, but to many others (most of them outside of the basic and extended tags). Copying all the tags might be awesome. Also, I have seen that LameXP doe snot properly detects "tags" on vorbis comment (used mostly on flac files) and either ignores them, or join them "Artist / Composer". Other software, like soundKonverter, does tag the fiels properly using the vorbis comment from the flac file.

Oh, and also, LameXP works perfectly on Linux with Wine 1.5.6 (Kubuntu 12.04, as a portable application). Too bad it does not have drag and drop support.

Sorry for the long post, but those are my observations after being using Lame after 4 months so far! Hope you keep the nice work with it. And thank you!

-Phantom-

20th June 2012, 04:51

I have a problem in converting flac 24b\96kHz to flac 16b\44.1kHz with lamexp
In program interface i can swich only sample rate.

Also there is a field for custom encoder parameters, but i need to know switches for changing bps and sample rate...

I would like to request to add cli reference (like "flac --help") for custom encoding parameters. Something like a "?" button near edit field.

ps:
parameters is
--bps=16 --sample-rate=44100

upd:
after specifying the parameters, lame xp encode audiofiles without changing bps and sr
LameXP v4.05 (Build #1038), compiled on 2012-06-21 at 18:26:06

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

C:/Temp/53389f20806a42b2a7a4c3476198ac42/lamexp_flac.exe -d -F -f -o C:\Temp\53389f20806a42b2a7a4c3476198ac42\68b4f6fc28a34c9db5ae312a0b06cd23.wav "G:\Downloads Torrents\Kreator-Phantom_Antichrist-EP-FLAC-2012-SCORN\a1. phantom antichrist (edit).flac"

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

Exited with code: 0x0000

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

C:/Temp/53389f20806a42b2a7a4c3476198ac42/lamexp_sox.exe --i C:/Temp/53389f20806a42b2a7a4c3476198ac42/68b4f6fc28a34c9db5ae312a0b06cd23.wav

Input File : 'C:/Temp/53389f20806a42b2a7a4c3476198ac42/68b4f6fc28a34c9db5ae312a0b06cd23.wav'
Channels : 2
Sample Rate : 96000
Precision : 24-bit
Duration : 00:04:24.56 = 25397760 samples ~ 19842 CDDA sectors
File Size : 152M
Bit Rate : 4.61M
Sample Encoding: 24-bit Signed Integer PCM

Exited with code: 0x0000

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

C:/Temp/53389f20806a42b2a7a4c3476198ac42/lamexp_flac.exe -8 --channel-map=none -T "title=Phantom Antichrist (edit)" -T artist=Kreator -T "album=Phantom antichrist" -T "genre=Thrash Metal" -T date=2012 -T track=1 --bps=16 --sample-rate=44100 -f -o "G:\Downloads Torrents\Kreator-Phantom_Antichrist-EP-FLAC-2012-SCORN\a1. phantom antichrist (edit) (3).flac" C:\Temp\53389f20806a42b2a7a4c3476198ac42\68b4f6fc28a34c9db5ae312a0b06cd23.wav

flac 1.2.1, Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007 Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
68b4f6fc28a34c9db5ae312a0b06cd23.wav: WARNING: legacy WAVE file has format type 1 but bits-per-sample=24
68b4f6fc28a34c9db5ae312a0b06cd23.wav: wrote 104742704 bytes, ratio=0,687

Exited with code: 0x0000

LoRd_MuldeR

20th June 2012, 21:33

First of all, thank you for this very nice piece of software. I totally love it (on windows).

You are welcome.

Not sure if someone have already reported this, but when you are about to split a cuesheet, and the created folder has the same name than a file on the folder, LameXP is unable to create the folder (So far I know, this may be an issue of the system itself), there is a way to detect this collition on LameXP and prevent this? (appending something to the name of the folder, for example).

It's a limitation of the file system. There can not be two items (files or sub-folders) within the same directory.

When LameXP generates the initial sub-folder name, it will check for existing folders and it will append "... (2)" when necessary.

It does not check for existing files of that name though. Collisions with files are highly unlikely, because files almost always have an extension (while folders almost always do not).

Anyway, I will make the check more throughout to avoid problems...

Also, Other things I have noticed is that LameXP "discards" tracks when they have a name "too long". This have happened me with some japanese albums that have "long names". You have to manually rename folders and try again in order to get the ommited tracks included the next time. A bit annoyning, but not so really an issue of LameXP, but detecting this too might be nice.

Maybe you were running into the MAX_PATH (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath) limitation of the file system. If so, there's not much we can do here...

Continuing with the topic, but this time talking about cue sheets in general... There is a way to prevent to loss the already added splitted tracks?
Let's say that you had a LameXP crash while trying to add a cue sheet, but you had added previously other cues to the convertion queue. All of them get lost after that. While it is not a big deal when you have splitted only an album... it can be annoyning if you had 20 or more getting ready to be transcoded... because you have to split them all again (to keep the metadata), so far I know.

LameXP usually won't crash :p

But if it did crash, you could simply re-add the files that have been split previosuly. You don't have to split them again. They'll still be there.

And of course, the last one is also related to the cuesheets. There is a way to "batch add" cueshets? Like we do with regular files? Havng the splitter is wonderfull, but maybe the dropzone might also work as a detection zone (if a cue sheet is dropped there) and try to "split" the cue in the bagground and add the resulting files to the queue. But this will be a plus.

This is not currently implemented. And it would not be easy to implement that on top of current Cue Sheet import dialog.

Other things I have found are related to the tags of th encoded files. For example, if the file has a "Composer" tag, it is not copied to the newy encoded file. That happens not only to that tag, but to many others (most of them outside of the basic and extended tags). Copying all the tags might be awesome. Also, I have seen that LameXP doe snot properly detects "tags" on vorbis comment (used mostly on flac files) and either ignores them, or join them "Artist / Composer". Other software, like soundKonverter, does tag the fiels properly using the vorbis comment from the flac file.

Well, this is not as easy as you might think. In order to "copy" a specific meta tag, you need to extract/parse that info from the original file first. Then you need to re-embedd it into the new file.

To make thinks worse, different file formats use/support different tags. Sometimes the same thing is called slightly different in different file formats. Or there is no clear standard on what tags are supported.

For LameXP I tried to find the "lowest common denominator" for alle file formats we deal with. "Composer" currently is not one of the tags supported by LameXP's internal representation...

Oh, and also, LameXP works perfectly on Linux with Wine 1.5.6 (Kubuntu 12.04, as a portable application). Too bad it does not have drag and drop support.

LameXP does support Drag&Drop, so this might be a bug/limitation of Wine. There are other problems with Wine.

So using LameXP under Linux via Wine is not the prefect way. A native Linux version of LameXP is on my TODO list and thanks to Qt this shouldn't be impossible.

But as quite some Windows-specific code has aggregated over the years, this will be a huge project :rolleyes:

(First step will be making LameXP compile with MinGW/GCC under Windows)

mariush

20th June 2012, 22:21

It's a limitation of the default functions you use to handle files in the application.

Maybe you were running into the MAX_PATH limitation of the file system. If so, there's not much we can do here...

This is also false. You can... Read on.

By default, the API functions will not (or should not) allow you to create files or folders with dot or space at the end. The file system can handle it just fine.

But an application can work around that, by using UNC names... read this page on MSDN: http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx#fully_qualified_vs._relative_paths

Basically, for example ... create a folder TEMP in C:\

Create a text file called "a.txt" - this works.
Create a folder called "a" - this works.

So far, it's possible to create a folder with the same name as a file, as long as there's no extension or dot at the end

Create a folder called "a." - by default it won't let you. However, you can open a command prompt and type there:

C:\> mkdir "\\?\C:\temp\a."

and you'll see a folder titled "a." in that folder. Windows should open it, you might even copy and delete files in it, but you won't be able to delete it.

Run

c:\> rmdir "\\?\C:\temp\a."

to delete it.

You can use this prefix to create paths longer than 257 ASCII (well, whatever the default Windows page is) characters... just be sure to send each character as two bytes in the API functions... as in "\ \ ? \ C : \ ... "

User will be able to do whatever it wants with the files and everything but some applications may have problems with it... for example Windows Explorer may not delete the folder if the whole path is longer than 257 characters. User can rename a folder that's before the folder with the music, to bring the whole path below the 257 character limit and then he'll be able to move/delete/etc the folder with the music.

So... I don't know what to say, it may be a future worth implementing, but user should at least be warned if the total path will be longer than 257 characters (or whatever MAX_PATH is set to)

LoRd_MuldeR

20th June 2012, 22:32

Well, technically some of the functions in the Win32 API may be "forced" to accept paths longer than MAX_PATH by using UNC paths. But not all of them.

Also the following warning should be considered:
The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not able to interpret properly.

AFAIK the Windows Explorer doesn't permit the user to create folders with a path exceeding MAX_PATH characters. And it might not be able to access such a folder created by another application.

Last but not least: LameXP avoids using the Win32 API directly and instead uses the appropriate Qt classes for file access. I have no idea if these can work with UNC names.

(And even if they did, on the Windows platform, this probably would destroy portability)

Kadai

21st June 2012, 08:00

First, thank you for the answers!

Now...

But if it did crash, you could simply re-add the files that have been split previosuly. You don't have to split them again. They'll still be there.

I have seen them when I have splitted from cue sheets, but for what I was referring is that, since they are wav files, they do not have any metadata on them... or they have?
To be honest, I have never added the splitted wav files. Just assumed that the metadata got lost. And after all, that is the important if you are splitting many files.

Well, this is not as easy as you might think. In order to "copy" a specific meta tag, you need to extract/parse that info from the original file first. Then you need to re-embedd it into the new file.

To make thinks worse, different file formats use/support different tags. Sometimes the same thing is called slightly different in different file formats. Or there is no clear standard on what tags are supported.

For LameXP I tried to find the "lowest common denominator" for alle file formats we deal with. "Composer" currently is not one of the tags supported by LameXP's internal representation...

Yup, I do myself understand that. But to what I was referring is that I see very different results from LameXP and from other encoding software (namely, soundKonverter). See the screenshots:

Original Flac Files, and LameXP output files:
http://img820.imageshack.us/img820/5463/lamexpoutput.png (http://imageshack.us/photo/my-images/820/lamexpoutput.png/)

Original Files, and soundKonverter output files:
http://img207.imageshack.us/img207/2743/soundk.png (http://imageshack.us/photo/my-images/207/soundk.png/)

The main thing is that maybe LameXP is reading a tag it is not supposed to read )on that case), because it places there the "Arranger" rather than the "Artist". But it may be an isolated case, because those flac files appear to use this scheme: http://i.imgur.com/UAazk.png

But this may help LameXP to improve about tag accuracy when re-embedding them.

LameXP does support Drag&Drop, so this might be a bug/limitation of Wine. There are other problems with Wine.

So using LameXP under Linux via Wine is not the prefect way. A native Linux version of LameXP is on my TODO list and thanks to Qt this shouldn't be impossible.

But as quite some Windows-specific code has aggregated over the years, this will be a huge project :rolleyes:

(First step will be making LameXP compile with MinGW/GCC under Windows)

Thank you for your effort on this! And when I was talking about "Drag & Drop", I was referring about Linux! (It does not work, at least not on my system).

Despite that, I'm using LameXP over the native soundKonverter because your software is way better on doing the job and options.

...

Oh, and a last issue that I have remembered: When loading a cue-sheet that its on ANSII coding, it would be nice to have the encodings have a name attached to it. Having, for example, "IBM-1234" as an option is not as descriptive as maybe "IBM-567 (Languaje)". But I have work-around it myself converting the files to UTF-8 before dropping them on Lame.

By the way, thanks again!

LoRd_MuldeR

21st June 2012, 19:52

LameXP v4.05 Alpha-5

Changes between v4.04 and v4.05:
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated mpg123 decoder to v1.14.2 (2012-05-12), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.57 (2012-05-02), compiled with ICL 12.1.7 and MSVC 10.0
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files
* Fixed a problem with Cue Sheet import and files that contain trailing dots in their name

LoRd_MuldeR

8th July 2012, 23:39

LameXP v4.05 Alpha-6

Changes between v4.04 and v4.05:
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated Qt runtime libraries to v4.8.2 (2012-04-26), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.14.2 (2012-05-12), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.57 (2012-05-02), compiled with ICL 12.1.7 and MSVC 10.0
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files
* Fixed a problem with Cue Sheet import and files that contain trailing dots in their name

LoRd_MuldeR

12th July 2012, 23:08

LameXP v4.05 Alpha-7

Changes between v4.04 and v4.05:
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated Qt runtime libraries to v4.8.2 (2012-04-26), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.14.3 (2012-07-01), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.58 (2012-05-28), compiled with ICL 12.1.7 and MSVC 10.0
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files
* Fixed a problem with Cue Sheet import and files that contain trailing dots in their name
* Workaround for a bug (feature?) of Qt's command-line parser that screwed up some arguments

LoRd_MuldeR

20th July 2012, 23:59

LameXP v4.05 Alpha-8

Changes between v4.04 and v4.05:
* Added support for Opus Audio Codec, based on Opus-Tools v0.1.3 (2012-07-10) by Xiph.org/Mozilla
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated Qt runtime libraries to v4.8.2 (2012-05-22), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.14.3 (2012-07-01), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.58 (2012-05-28), compiled with ICL 12.1.7 and MSVC 10.0
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files
* Fixed a problem with Cue Sheet import and files that contain trailing dots in their name
* Workaround for a bug (feature?) of Qt's command-line parser that screwed up some arguments

Limitations regarding Opus support:
* Opus-Tools don't support Unicode filenames (on the Windows platform), so I will have to fix that myself - at a later time
* Opus-Tools don't report real-time progress while encoding/decoding (actually the encoder does report progress, but the required flush operation appears to be missing)
* Detection of input Opus files is provisional, most info is not detected. This will be fixed as soon as we update to a newer MediaInfo with Opus support.

LoRd_MuldeR

21st July 2012, 22:59

LameXP v4.05 Alpha-10

Changes between v4.04 and v4.05:
* Added support for Opus Audio Codec, based on Opus-Tools v0.1.3 (2012-07-10) by Xiph.org/Mozilla
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated Qt runtime libraries to v4.8.2 (2012-05-22), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.14.3 (2012-07-01), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.58 (2012-05-28), compiled with ICL 12.1.7 and MSVC 10.0
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files
* Fixed a problem with Cue Sheet import and files that contain trailing dots in their name
* Workaround for a bug (feature?) of Qt's command-line parser that screwed up some arguments

Now LameXP using a custom Opus encoder, which should resolve most of the limitations (patch (https://git.xiph.org/?p=users/greg/opus-tools.git;a=commitdiff;h=58347273ab4c9e9d30ab8ffd62acbac348f7e0c8;hp=4cc06a7f0fe7cd93196e3078bcf1b7c1b0e0c934)). Also more Opus-specific options are exposed now!

BTW: If you are looking for an Opus-capable player software, you may want to give foobar2000 v1.1.14 beta-1 (http://www.foobar2000.org/) a try ;)

LoRd_MuldeR

29th July 2012, 16:10

LameXP v4.05 Alpha-12

Changes between v4.04 and v4.05:
* Added support for Opus Audio Codec, based on Opus-Tools v0.1.3+ (2012-07-26) by Xiph.org/Mozilla
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated Qt runtime libraries to v4.8.2 (2012-05-22), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.14.3 (2012-07-01), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.58 (2012-05-28), compiled with ICL 12.1.7 and MSVC 10.0
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files
* Fixed a problem with Cue Sheet import and files that contain trailing dots in their name
* Workaround for a bug (feature?) of Qt's command-line parser that screwed up some arguments

Note: LameXP now includes a build of the Opus encoder with "experimental encoder perceptual tuning" (exp_analysis7).

hoboX10

29th July 2012, 23:39

Hey Mulder, I just want to let you know that your latest stable release has a weird bug when you encode to AAC. (At least from MP3). The output file contains both the AAC audio track AND the MP3 track, but they aren't listed as separate audio tracks like different audio languages are. They play at the same time and it is very strange.

If this is already known, then I'm sorry for the spam. Thanks for the awesome program I've been using LameXP for years.

Edit: I installed one of the alpha builds and it doesn't have the issue. It's good enough for me, I was just letting you know of it.

LoRd_MuldeR

30th July 2012, 00:05

hoboX10, LameXP certainly does not multiplex multiple audio streams into a single file. Also the (default) AAC encoder used by LameXP, Nero AAC, hasn't changed in years and won't do anything like that.

Thus I assume this is actually a playback issue. Your playback software probably assumes that the .MP4 file is a video and loads the .MP3 file as an additional audio track ;)

If you are 100% sure that this is NOT some playback issue, then please create a MediaInfo (http://mediainfo.sourceforge.net/en) report (in "text" mode!) from the "problematic" MP4 file (as generated by LameXP) and send the report to me via PM.

Furthermore you may want to post your LameXP log: Once the encoding process has finished, don't close the processing window, double-click on one of the items in the list and then copy the text...

LoRd_MuldeR

1st August 2012, 22:03

LameXP v4.05 Alpha-13

Changes between v4.04 and v4.05:
* Added support for Opus Audio Codec, based on Opus-Tools v0.1.3+ (2012-07-26) by Xiph.org/Mozilla
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated Qt runtime libraries to v4.8.2 (2012-05-22), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.14.3 (2012-07-01), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.58 (2012-07-31), compiled with ICL 12.1.7 and MSVC 10.0
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files
* Fixed a problem with Cue Sheet import and files that contain trailing dots in their name
* Workaround for a bug (feature?) of Qt's command-line parser that screwed up some arguments

The updated version of MediaInfo will now properly detect Opus files with full info. Provisional Opus detection code was removed.

LoRd_MuldeR

5th August 2012, 15:46

LameXP v4.05 Beta-1

Changes between v4.04 and v4.05:
* Added support for Opus Audio Codec, based on Opus-Tools v0.1.3+ (2012-07-26) by Xiph.org/Mozilla
* Added Swedish translation, thanks to Åke Engelbrektson <eson57@gmail.com>
* Updated Qt runtime libraries to v4.8.2 (2012-05-22), compiled with MSVC 10.0
* Updated mpg123 decoder to v1.14.4 (2012-07-26), compiled with GCC 4.6.1
* Updated MediaInfo to v0.7.58 (2012-07-31), compiled with ICL 12.1.7 and MSVC 10.0
* Implemented multi-threading in file analyzer for faster file import (about 2.5x to 6.0x faster!)
* Implemented multi-threading in initialization code for faster application startup
* Fixed a potential crash (stack overflow) when adding a huge number of files
* Fixed a problem with Cue Sheet import and files that contain trailing dots in their name
* Workaround for a bug (feature?) of Qt's command-line parser that screwed up some arguments

SeeMoreDigital

5th August 2012, 21:19

LameXP v4.05 Alpha-8
Added support for Opus Audio Codec, based on Opus-Tools v0.1.3+ (2012-07-26) by Xiph.org/Mozilla
Well... I had a quick look on the forum but was unable to find a decoder filter for Opus. Can anyone oblige?

LoRd_MuldeR

5th August 2012, 21:25

Well... I had a quick look on the forum but was unable to find a decoder filter for Opus. Can anyone oblige?

I'm not exactly sure what kind of "filter" you are referring to, but the Opus Tools include both, an encoder and decoder tool.

I have put up a stand-alone download here:
https://code.google.com/p/mulder/downloads/list?can=2&q=Opus+Tools

Of course the easiest way would be using LameXP to decode the Opus files ;)

And, as mentioned before, if you are looking for player software that handles Opus files directly, get the latest Foobar2000.

Last but not least, an up-to-date Firefox will handle Opus via HTML 5 <audio> tag.

SeeMoreDigital

5th August 2012, 21:35

And, as mentioned before, if you are looking for player software that handles Opus files directly, get the latest Foobar2000.

Bummer... Is that the only player able to decode/play Opus audio files :eek:

By-the-way... Have you tried muxing .opus files using MKVmerge GUI? It would not work for me!

LoRd_MuldeR

5th August 2012, 21:46

Keep in mind that Opus is still pretty new and has just been standardized ;)

At this point, I don't know of any Opus-enabled players other than Foobar2000 and Firefox. But you can be sure Opus support will be added to VLC, MPlayer and friends soon (if not done yet).

Also I would really be surprised if nobody writes a Winamp plug-in and a DirectShow decoder for Opus...

[EDIT]

As for your question about MKVmerge, I have no idea :o

As far as I know, storing Opus streams in Matroska containers is supposed to work, but is the specification for that fixed yet? And if so, is it implemented in MKVmerge already?

Brazil2

7th August 2012, 11:41

At this point, I don't know of any Opus-enabled players other than Foobar2000 and Firefox.

Also I would really be surprised if nobody writes a Winamp plug-in and a DirectShow decoder for Opus...
Any BASS (http://www.un4seen.com) based player (XMPlay, AIMP, 1by1, <more>) can play OPUS using this DLL:
http://www.un4seen.com/forum/?topic=13870.0

And DirectShow players can use DC-Bass Source Mod for OPUS playback:
http://reino.degeelebosch.nl

LoRd_MuldeR

7th August 2012, 21:36

LameXP v4.05 Beta-2

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

manolito

8th August 2012, 18:53

From the changelog of MkvТоMp4 v0.221:
6. Ability to use QT library for encoding without having to install QuickTime player or iTunes.

Looks like oreons found a way to use qaac without installing Apple Application Support...

Could this be implemented in LameXP?

Cheers
manolito

//Edit//
Looks like oreons promised too much...
qaac encoding does not work on my machine without QuickTime or iTunes

LoRd_MuldeR

8th August 2012, 20:45

AFAIK, older versions of QAAC were accessing the Apple AAC encoder through QuickTime (or some component of it), thus an installation of QuickTime was inevitable.

However "since [version] 1.00, qaac directly uses CoreAudioToolbox.dll. Therefore, QuickTime installation is no more required. However, Apple Application Support is required" (source (https://sites.google.com/site/qaacpage/)).

I think that's all what oreons was referring to! Also note that you can install either iTunes, QuickTime or Safari in order to obtain the required Apple Application Support...

QAAC probably will never work without CoreAudioToolbox.dll, for obvious reasons. And installing the Apple Application Support is the only way to get that DLL pus its dependencies.

(BTW: I don't know if Apple offers the "AppleApplicationSupport.msi" as a stand-alone download, but you may extract it from the "QuickTimeInstaller.exe" via 7-Zip)

LoRd_MuldeR

13th August 2012, 20:27

LameXP v4.05 Beta-3

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

Note: This update also fixes a regression, introduced in v4.05 Alpha-1, which could cause multiple temporary folders to be created in your %TEMP% directory, but only one of them gets clean-up.
If you used any of the previous LameXP v4.05 Alpha/Beta versions, then it is highly recommended that you check your %TEMP% directory and clean it up manually, if required...

manolito

16th August 2012, 16:43

QAAC probably will never work without CoreAudioToolbox.dll, for obvious reasons. And installing the Apple Application Support is the only way to get that DLL pus its dependencies.

Well, oreons actually did manage to support qaac without installing Apple Application support. I just set it up wrong (I ticked "QuickTime" when I should have ticked "CoreAudioToolbox").

Now of course my question again if this could be implemented in LameXP. As far as I can see it only requires 4 DLLs in the program folder. I have no idea about dependencies, but MkvToMp4 comes without an installer, so it cannot be too hard...

Cheers
manolito

LoRd_MuldeR

16th August 2012, 19:05

Well, as said before, QAAC will unavoidably require the CoreAudioToolbox.dll, because that is where the Apple AAC encoder is implemented.

Whether you need to run the Apple Application Support installer to get CoreAudioToolbox working, that is a different question ;)

It probably is sufficient to just drop CoreAudioToolbox.dll plus its dependencies (I count at least eight (http://img440.imageshack.us/img440/1010/coreaudiodll.png) more dependencies!) into the application directory or the System directory, so QAAC can find and load it.

But, as we cannot redistribute CoreAudioToolbox.dll (and friends) for legal reasons, the users will have to download the Apple Application Support (or a product that contains it) from the Apple site anyway.

And for most users it will be much easier to just let the installer do its job, instead of trying to extract the required DLL's from the setup package manually...

manolito

16th August 2012, 22:17

Of course your reply is not really satisfactory for me, so I did a little research...

Apple Application Support can be extracted from QuickTime or iTunes and can be installed separately, but it is still bloated. It uses more than 60 MB on the HDD, it installs an autorun entry for APSDaemon.exe, and it adds a Windows Firewall exception for WebKit. A little much for my taste.

Since oreons succeeded in making MkvToMp4 use qaac without installing Apple Application Support, my first attempt was to make LameXP use the CoreAudio files from MkvToMp4. But this did not work so far.

The second best approach was to install Apple Application Support, but strip it down to only the essential files. And this did work...:D

This is the procedure:

1. Download QuickTime or iTunes, open the file with 7-Zip and extract AppleApplicationSupport.msi. Install it by doubleclicking it.

2. Open RegEdit, go to HKLM/Software/Microsoft/Windows/CurrentVersion/Run and delete the entry for APSDaemon.

3. Open your Firewall settings and remove the exception for WebKit.

4. Run Explorer, navigate to Program Files/Common Files/Apple/Apple Application Support. Delete all subfolders. Delete all files in the root folder except:
ASL.dll
CoreAudioToolbox.dll
CoreFoundation.dll
icudt46.dll
libdispatch.dll
libicuin.dll
libicuuc.dll
obj.dll
pthreadVC2.dll

5. Reboot

The size of your Apple folder will now be only 23 MB, and the software will not make home calls any more...

Cheers
manolito

LoRd_MuldeR

16th August 2012, 22:42

You really worry about 60 MB in times where the OS alone easily takes 10-15 GB of HDD space? :confused:

Anyway, if you want to be really paranoid and avoid installing Apple Application Support by all means, you can extract the CoreAudioToolbox DLL files from the "AppleApplicationSupport.msi" file via 7-Zip.

Put them into a sub-folder called "QTfiles" which you create inside the directory where the "qaac.exe" resides and you are done. There is no MkvToMp4 "magic" needed for that...

manolito

16th August 2012, 23:31

You really worry about 60 MB in times where the OS alone easily takes 10-15 GB of HDD space?
It is not so much the size as the "Call-Home" feature. And I remember some person quite recently also had strong reservations against installing this kind of software:
About iTunes: The only thing I can say is that personally I wouldn't infect my computer with a mess like iTunes or QuickTime...

you can extract the CoreAudioToolbox DLL files from the "AppleApplicationSupport.msi" file via 7-Zip.

Put them into a sub-folder called "QTfiles" which you create inside the directory where the "qaac.exe" resides and you are done. There is no MkvToMp4 "magic" needed for that...

That would have been nice, but it does not work. Using the latest LameXP beta, qaac addin version from 05-08-2012. Still getting the error
QAAC version couldn't be determined -> QAAC support will be disabled!

Cheers
manolito

//Edit//
Alright, I think I figured it out...:)
The subfolder QTfiles needs another subfolder called "Microsoft.VC80.CRT" which must contain the files
msvcr80.dll
msvcp80.dll
Microsoft.VC80.CRT.manifest

It looks like the easiest way to make this work under LameXP is to pull the whole QTFiles folder from MkvToMp4 and copy it into the LameXP folder.

LoRd_MuldeR

16th August 2012, 23:51

It does work for me. Tested on a "clean" VM.

Make sure "qaac.exe" as well as "libsoxrate.dll" are located in your LameXP directory. All the CoreAudioToolbox DLL's go into a sub-folder "QTfiles".

You may verify that QAAC is working properly by running "qaac.exe --check" from the LameXP directory...

[EDIT]

Indeed, the Apple Application Support DLL's depend on the Visual C++ 2005 Runtime libraries. Thus you will need the Microsoft Visual C++ 2005 Redistributable Package (http://www.microsoft.com/en-us/download/details.aspx?id=3387), if you happen to not have that installed yet.

Also you don't need a "special" QAAC binary from MkvToMp4, the build included in the LameXP Add-in should work fine. The CoreAudioToolbox DLL's need to be obtained from Apple web-site for legal reasons...

manolito

17th August 2012, 01:06

Indeed, the Apple Application Support DLL's depend on the Visual C++ 2005 Runtime libraries. Thus you will need the Microsoft Visual C++ 2005 Redistributable Package (http://www.microsoft.com/en-us/download/details.aspx?id=3387), if you happen to not have that installed yet.

Well, I do not have a "Clean Machine", but I do have several versions of the VC runtimes installed. Whenever an application needed to install a VC runtime, I let it do it. And my Windows updates are done through WSUSOffline, so my VC redistributables are always up to date. My uninstall window looks like this:
http://www.bilderload.com/bild/236509/vcZ2SYK.png (http://www.bilderload.com)

Still qaac refused to work without the "Microsoft.VC80.CRT" subfolder under the Qtfiles folder. Oh well...:(

I've got another request, though. When more than one AAC encoder is installed, FHG takes precedence over Nero, and qaac takes precedence over FHG. For people like me who always love to have choices, would it be possible to add a selection box to LameXP so if more than one AAC encoder is installed we could easily pick the one we want from within the GUI?

Cheers
manolito

LoRd_MuldeR

17th August 2012, 12:17

The VS2005 and VS2008 runtime libraries are handled by WinSxS (Windows Side-by-Side) and thus they actually need to be installed. Just putting the runtime DLL's into the application directory won't work with these VS versions. Once the VS2005/VS2008 redistributable package has been installed, WinSxS will take care of providing each applications with the proper DLL (version). Also Windows Update will take care of keeping the DLL's managed by WinSxS up-to-date. It is also possible to provide assemblies (DLL files) as "private assemblies" (http://msdn.microsoft.com/en-us/library/ff951638%28v=vs.85%29) by putting them into a specific sub-folder along with a suitable Manifest file. This is intended for assemblies that, unlike the C++ Runtime libs, are not supposed to be used by multiple applications. Starting with VS2010, the C++ Runtime libs are no longer maintained by WinSxS though.

About adding an option to choose the AAC encoder at runtime: This certainly would be possible, but it would be yet another complication. I see that such an option would be nice for switching between the different encoders quickly, in case you are doing some encoder comparison. But most users will probably install their preferred AAC encoder once and then stick with it. If, for example, somebody installs the Add-in for FHG-AAC or for QAAC, we can be pretty sure the user actually wants to use that encoder...

GrofLuigi

17th August 2012, 18:16

From using Safari on Windows (and thus AAS) i know that it requires a very fresh version of VS redistributables. Probably the "ATL security update" or even later. It is compiled that way.

GL

LoRd_MuldeR

17th August 2012, 20:29

LameXP v4.05 Beta-4

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

Note: This update also fixes a regression, introduced in v4.05 Alpha-1, which could cause multiple temporary folders to be created in your %TEMP% directory, but only one of them gets clean-up.
If you used any of the previous LameXP v4.05 Alpha/Beta versions, then it is highly recommended that you check your %TEMP% directory and clean it up manually, if required...

manolito

17th August 2012, 21:21

Just a quick note for users of the stable version 4.04:
Make sure "qaac.exe" as well as "libsoxrate.dll" are located in your LameXP directory. All the CoreAudioToolbox DLL's go into a sub-folder "QTfiles".
This method also works with version 4.04 using the LameXP.qaac-addin.2012-03-06.zip.

And it is not necessary to copy All the CoreAudioToolbox DLL's. Only these 9 files need to be copied:
ASL.dll
CoreAudioToolbox.dll
CoreFoundation.dll
icudt46.dll
libdispatch.dll
libicuin.dll
libicuuc.dll
obj.dll
pthreadVC2.dll

Cheers
manolito

LoRd_MuldeR

21st August 2012, 23:16

LameXP v4.05 RC-1

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

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

Atak_Snajpera

22nd August 2012, 11:32

Opus encoding does not work in ABR mode

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

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

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

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

Exited with code: 0x0000

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

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

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

Exited with code: 0x0000

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

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

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

Exited with code: 0x0001

Regarding opus advanced settings

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

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

LoRd_MuldeR

22nd August 2012, 12:07

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

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

Atak_Snajpera

22nd August 2012, 12:14

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

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

LoRd_MuldeR

22nd August 2012, 12:20

They do something. Though not what one may expect.

Opus operates in 3 modes:

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

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

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

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

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

Atak_Snajpera

22nd August 2012, 12:24

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

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

Atak_Snajpera

22nd August 2012, 12:41

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

LoRd_MuldeR

22nd August 2012, 12:54

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

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

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

Atak_Snajpera

22nd August 2012, 13:03

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

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

LoRd_MuldeR

22nd August 2012, 13:07

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

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

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

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

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

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

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

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

For the rest you can use oldschool method

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

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

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

Atak_Snajpera

22nd August 2012, 13:24

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

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

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

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

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

LoRd_MuldeR

22nd August 2012, 13:29

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

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

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

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

Atak_Snajpera

22nd August 2012, 13:53

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

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

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

manolito

22nd August 2012, 14:46

Hey Atak,

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

Cheers
manolito

LoRd_MuldeR

22nd August 2012, 14:59

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

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

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

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

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

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

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

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

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

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

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

Atak_Snajpera

22nd August 2012, 15:44

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

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

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

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

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

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

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

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

LoRd_MuldeR

22nd August 2012, 22:55

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

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

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

pururin

23rd August 2012, 12:16

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

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

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

LoRd_MuldeR

23rd August 2012, 18:46

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

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

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

pururin

24th August 2012, 10:52

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

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

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

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

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

-Also thanks a lot for the answer about dithering!

LoRd_MuldeR

24th August 2012, 15:52

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

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

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

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

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

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

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

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

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

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

Atak_Snajpera

24th August 2012, 17:56

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

LoRd_MuldeR

24th August 2012, 18:34

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

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

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

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

LoRd_MuldeR

24th August 2012, 22:05

LameXP v4.05 RC-3

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

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

Atak_Snajpera

28th August 2012, 12:01

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

LoRd_MuldeR

28th August 2012, 17:04

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

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

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

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

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

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

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

Atak_Snajpera

29th August 2012, 09:59

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

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

Important note

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

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

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

pururin

29th August 2012, 16:08

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

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

LoRd_MuldeR

29th August 2012, 16:35

I had a quick look at lossyWave.

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

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

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

Atak_Snajpera

29th August 2012, 17:10

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

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

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

LoRd_MuldeR

4th September 2012, 00:14

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

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

pururin

4th September 2012, 11:23

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

manolito

10th September 2012, 02:58

I have a problem with 4.05 final:

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

Does LameXP ignore my temp folder setting?

Cheers
manolito

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

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

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

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

LoRd_MuldeR

10th September 2012, 12:04

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

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

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

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

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

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

manolito

10th September 2012, 18:41

Thx...:):):)

Cheers
manolito

LoRd_MuldeR

18th September 2012, 00:02

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

Seems to be resolved now :)

datauser

18th September 2012, 11:48

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

The decoded file exceeds 4GB, problems might occur.

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

LoRd_MuldeR

18th September 2012, 12:15

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

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

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

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

manolito

18th September 2012, 19:24

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

Cheers
manolito

datauser

19th September 2012, 11:51

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

LoRd_MuldeR

7th October 2012, 23:52

LameXP v4.06 Beta-1

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

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

LoRd_MuldeR

9th October 2012, 23:03

LameXP v4.06 Beta-2

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

LoRd_MuldeR

14th October 2012, 23:56

LameXP v4.06 Beta-3

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

LoRd_MuldeR

19th October 2012, 22:38

LameXP v4.06 RC-1

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

Motenai Yoda

20th October 2012, 09:42

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

thanks

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

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

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

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

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

Exited with code: 0xC0000409

LoRd_MuldeR

24th October 2012, 23:43

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

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

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

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

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

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

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

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

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

LoRd_MuldeR

25th October 2012, 00:00

LameXP v4.06 RC-2

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

Motenai Yoda

25th October 2012, 14:44

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

neroAacDec.exe can work?

the file is made with lamexp and qaac.

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

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

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

maybe should be a folder\name problem?

LoRd_MuldeR

25th October 2012, 20:09

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

neroAacDec.exe can work?

the file is made with lamexp and qaac.

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

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

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

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

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

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

maybe should be a folder\name problem?

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

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

Motenai Yoda

25th October 2012, 21:50

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

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

LoRd_MuldeR

25th October 2012, 22:05

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

LoRd_MuldeR

25th October 2012, 22:46

Okay, after some debugging I found the cause of the issue!

When FAAD2 prints out the current Progress, it first writes the text "[x%] decoding <filename>" into an internal buffer, before it then actually prints that text out to the console. And, as this text includes the filename, the size of the buffer that is required to hold the text, depends on the length of the file name, obviously. For some reason, however, they made the buffer only 200 characters long. With very long file names this can be too short and we get a nice buffer overrun!

Motenai Yoda

26th October 2012, 06:29

how do u fixed? Can I suggest to simply use cout<< operator to concatenate and push out the strings, or use something like strCount() or size_of() to know how long the filename is?

LoRd_MuldeR

26th October 2012, 12:47

I increased the buffer from 200 to 300 char's, which should be enough, assuming file name won't exceed MAX_PATH char's. But to be sure, and because in UTF-8 encoding one "character" can take multiple char's (bytes), I also replaced the highly unsafe sprintf() with the safe snprintf_s(). Using the "cout" object is not possible in a plain C program, that is C++ stuff. And sizeof() doesn't tell you anything, if you have char* pointer.

BTW: It seems all the reason why they print into a buffer first, instead of using printf() right away, is because they are going to pass the same text into SetConsoleTitle() too.

(The patch will be included in the LameXP repository, as always)

LoRd_MuldeR

27th October 2012, 16:32

LameXP v4.06 RC-3

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

Note: Because home.pages.at has stopped the service after many years, my web-site sadly is no longer available under the "free.pages.at" address :(

The following mirrors are still available: #1 (http://mulder.brhack.net/) #2 (http://mulder.bplaced.net/) #3 (http://mulder.cwsurf.de/) #4 (http://mulder.6te.net/)

LoRd_MuldeR

29th October 2012, 00:07

LameXP v4.06 RC-4

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

LoRd_MuldeR

1st November 2012, 01:51

LameXP v4.06 RC-5

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

LoRd_MuldeR

4th November 2012, 18:34

LameXP v4.06 has been released :)

Changes between v4.05 and v4.06 [2012-11-04]:
* Updated Opus encoder/decoder libraries to v1.0.1 and Opus-Tools to v0.1.5 (2012-09-22)
* Updated mpg123 decoder to v1.14.4+ (2012-09-24), compiled with GCC 4.7.1
* Updated ALAC decoder to refalac v0.56 (2012-10-24), based on reference implementation by Apple
* Updated Qt runtime libraries to v4.8.3 (2012-09-13), compiled with MSVC 10.0
* Updated MediaInfo to v0.7.61+ (2012-10-28), compiled with ICL 12.1.7 and MSVC 10.0
* Updated language files (big thank-you to all contributors !!!)
* Fixed a bug with the "Store temporary files in your system's default TEMP director" checkbox
* Fixed a buffer overflow in FAAD2 decoder which could cause crashes with very long file names
* Fixed a regression in Qt v4.8.3 that broke Drag&Drop support (details #1 (https://bugreports.qt-project.org/browse/QTBUG-27265)) (details #2 (https://codereview.qt-project.org/35297))
* Reworked the "About..." dialog – now using a custom dialog instead of message boxes

SeeMoreDigital

4th November 2012, 18:44

Downloading and installing now.... Many thanks :)

Dogway

8th November 2012, 01:49

at last LameXP doesn't have any conflict with Comodo on the new version.
The bad news is it doesn't recognise qaac.exe.
If you care for presentation, there's a mispell in spanish "Mostar DropBox", where it should be "Mostrar".
You're welcome : P

edit: found the hidden gem qaac.exe v.1.39, working great now, thanks!

LoRd_MuldeR

8th November 2012, 12:46

at last LameXP doesn't have any conflict with Comodo on the new version.

I didn't change anything... because there is nothing I could do, on my side, against buggy A/V software.

So I guess, whatever the problem in Comodo was, they have fixed the bug on their side...

See also:
http://lamexp.sourceforge.net/doc/FAQ.html#96205e91

The bad news is it doesn't recognise qaac.exe.

Please follow the install instructions here:
http://lamexp.sourceforge.net/doc/FAQ.html#71a113b0

You may need to update your QAAC add-in for LameXP, if yours is too old...

If you care for presentation, there's a mispell in spanish "Mostar DropBox", where it should be "Mostrar".
You're welcome : P

Well, I have to rely on traslators for all languages, except for English and German.

If you think you can improve the Spanish translation, please feel free to have a look at:
http://lamexp.sourceforge.net/doc/Translate.html

I will fix this one typo for the next release. So thanks for the report.

Dogway

8th November 2012, 17:37

You may need to update your QAAC add-in for LameXP, if yours is too old...
Yes I found out just right after posting.

I didn't do anything to Comodo (update database nor software) so I don't know, maybe it was something on your side (without noticing) or that I correctly enabled permissions, although I doubt I didn't do this the first time.

Thank you.

LoRd_MuldeR

15th November 2012, 19:05

http://img703.imageshack.us/img703/7214/clipboard04xj.png

For anybody who cares, here is the first Visual Studio 2012 build of LameXP:
http://www.mediafire.com/file/rl546gd6j4yvav1/LameXP-ALPHA.2012-11-15.Release-Static.Build-1188.exe

As one might expect, this build will not run on Windows XP (or even older). It also will need a CPU with SSE2 support, because Visual Studio defaults to /arch:SSE2 now and I didn't see a reason to change that. If the binary doesn't run on older OS anyway, it doesn't make any sense to still care about archaic CPU's. Other than that, you shouldn't see any difference with the new build.

SeeMoreDigital

15th November 2012, 20:22

For anybody who cares, here is the first Visual Studio 2012 build of LameXP:
http://www.mediafire.com/file/rl546gd6j4yvav1/LameXP-ALPHA.2012-11-15.Release-Static.Build-1188.exe

Thanks... It opens fine with Win7 32-bit ;)

manolito

15th November 2012, 20:55

LoRd_MuldeR

15th November 2012, 21:27

Don't worry, I won't drop Windows XP support!

Maybe I will make the switch to VS2012 after Microsoft has finally released the "Update 1" for VS2012, which is supposed to restore Windows XP targeting support, yay ;)

I don't know if it will be possible to restore Windows 2000 support the same way I could do it with VS2010, so I might be forced to drop Windows 2000 support.

(Currently I'm still undecided whether my eyes will be able to permanently bear the clunky interface of VS2012, but "Update 1" is also supposed to bring back some colors ^^)

Przemek_Sperling

20th November 2012, 11:12

I ripped some CDs and coded them with Opus. The quality is great but one thing seems to be a bit weird to me. As I ripped them from CDs the source is sampled at 44 kHz, but if I compress it with Opus and play with AIMP or foobar the players show 48 kHz sampling rate. Are the files resampled? Is it usual behavior for the codec orI am doing something wrong?

LoRd_MuldeR

20th November 2012, 11:45

Please see:
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=97051&view=findpost&p=808895

Opus does not natively support 44Khz. The idea is that since 48Khz can store a 44Khz signal, this simplifies the algorithm. Then, it just stores the original format and size so that a decoder could decode to the same values, but a decoder is allowed to decode at another samplerate. [...] Every non-48Khz input rate will internally be converted to 48Khz. So the output will always be at 48Khz. If you don't trust the internal resampler then you could always go and use something like SoX.

See also:
http://wiki.xiph.org/OpusFAQ#How_do_I_use_44.1_kHz_or_some_other_sampling_rate_not_directly_supported_by_Opus.3F

Note that it's generally preferable for a decoder to output at 48kHz even when you know the original input was 44.1kHz, not only because you can skip resampling but also because many inexpensive audio interfaces have poor quality output for 44.1k. [...] input files at these rates [above 48 kHz] are internally converted to 48 kHz, and then only frequencies up to 20 kHz are encoded. The reason is simple: lossy codecs are designed to preserve audible details while discarding irrelevant information. Since the human ear can only hear up to 20 kHz at best (usually lower than that), frequency content above 20 kHz is the first thing to go.

Przemek_Sperling

20th November 2012, 15:55

Thank you for the links. They explain everything :thanks:

LoRd_MuldeR

28th November 2012, 02:00

LameXP v4.07 Alpha-4

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Updated Qt runtime libraries to v4.8.4 (2012-11-23), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.5 (2012-11-23)

Note: This build was made with "Update 1" of Visual Studio 2012, so this build is supposed to work under Windows XP again (as opposed to Visual Studio 2012 RTM). If you encounter any issues under Windows XP, please report!

Kadai

2nd December 2012, 08:33

Not sure if someone has reported it yet... but (at least on Linux / Kubuntu 12.10 ... running LameXP on top of Wine) I have got a consistent problem when the tags of the files being encoded have quotes on the name.

For example, if the file has a title tag like (and named also): マジカ"ルゼ"アクション編曲バトル! ... the file won't convert and will threw a error.

This have happened to me with flac files, but they have something in common... the tags are UTF-8 encoded (so far I know).

Now, I'm not sure if this also happens on Windows (because I do not have a windows box at hand), but this error has been consistent with me, with the 4.06 final version, so I decided to report it.

Other one I have seen that threw me the error is:
ゆうかぜ (Yoshino Yoshikawa "Pollarstars" remix)

Hope it is helpful.

LoRd_MuldeR

2nd December 2012, 14:54

Hi, Kadai.

LameXP provides full Unicode support. Also all CLI tools used by LameXP either support Unicode file names or have been patched by me to support Unicode file names.

Nonetheless tags can still be problematic, because some tag formats, like ID3v1, do not defined which encoding/codepage is used. They simply store 8-Bit characters encoded in an undefined (system-specific) codepage. There neither is an indication of the codepage being used, nor is Unicode (e.g. UTF-8 or UTF-16) supported/used. Thus it is impossible to know which codepage was used to create those tags. If your system's default codepage for 8-Bit characters doesn't happen to be the same as the creator's codepage happened to be, then the tags will be read as garbage. That's not a limitation/bug of LameXP, but a shortcoming of the ID3v1 format! The only solution is using ID3v2 instead of ID3v1, because ID3v2 does properly support Unicode (it uses UTF-16 encoding by definition). Of course, if we have an existing file with only ID3v1 tag, there is nothing we could do :(

Anyway, even if the tag cannot be read correctly for the reasons explained before, this certainly shouldn't cause an error. So it's probably an issue with Linux/Wine. LameXP is currently Windows-only with Windows XP and Windows 7 being the primary platforms that I use for development and testing. Wine might work too, but there is no guarantee. Random things might break! I once tested Wine (Ubuntu 12.10) and couldn't find any serious issues, except for a few graphic glitches. But as you neither mentioned what error exactly you got nor provide an example file to reproduce the issue, it is impossible to say what happened.

If you provide the required info, I might be able to look into this more in detail...

LoRd_MuldeR

2nd December 2012, 18:13

LameXP v4.07 Alpha-5

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.5 (2012-11-23)

LoRd_MuldeR

8th December 2012, 01:29

LameXP v4.07 Alpha-6

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2012-12-07)
* Fixed handling of certain characters when passing meta tags on the command-line

SeeMoreDigital

12th December 2012, 22:34

Hi LoRd_MuldeR,

I've got some 'surround sound' DTS audio CD's that I'd like to convert to 6Ch FLAC files for storage and playback via my NAS.

As with all 'surround sound' DTS audio CD's, the extracted streams are (rather annoyingly) 2Ch PCM.WAV @ 1411Kbps 44.1 KHz/16-bits files!

Can LameXP be configured to convert such sources to 6Ch FLAC?

Cheers

LoRd_MuldeR

12th December 2012, 22:57

If it has been "extracted" as 2 channels (stereo) PCM already, how should we get a 6 channel signal from that? :confused:

Maybe you confused DTS with Dolby ProLogic? The latter indeed stores 4 channels (left, right, center, back) in a Stereo signal and the 4 channels can then be restored from the Stereo signal using a ProLogic decoder.

SeeMoreDigital

12th December 2012, 23:07

If it has been "extracted" as 2 channels (stereo) PCM already, how should we get a 6 channel signal from that? :confused:
Personally, I don't know ;)

A few years ago I seem to remember an application that could convert such sources. I think it was BeSweet based... I really can't remember for sure :eek:

LoRd_MuldeR

12th December 2012, 23:12

If that tool can generate a "true" 6 channel signal from only 2 channels, some magic must be involved :p

SeeMoreDigital

12th December 2012, 23:27

If that tool can generate a "true" 6 channel signal from only 2 channels, some magic must be involved :p
I can only imagine there's some channel decoding information within the DTS.WAV files header which is passed to the decoder...

If you're interested I can provide a short sample?!

LoRd_MuldeR

12th December 2012, 23:30

DTS streams can be stored in a RIFF/WAVE container and LameXP will handle such files just fine (using ValibDec).

If, however, it is a 2ch PCM WAVE file, as you said earlier, I don't see how this should be possible.

MediaInfo will reveal what it actually is...

SeeMoreDigital

13th December 2012, 15:53

MediaInfo will reveal what it actually is...MediaInfo reports the DTS files as containing 2 channels. Indeed, it does not recognise that the file contains DTS audio!

However, VLC player (along with MediaPlayer Classic) reports the DTS files as containing 6 channels: -

http://i45.tinypic.com/2port3a.png

And when the bit-stream is passed to a DSS amp via SPDIF or HDMI you obtain six 'discrete' DTS channels...

Cheers

LoRd_MuldeR

13th December 2012, 16:56

Looks like we have a DTS stream that was put into a WAVE/RIFF Container as if it was PCM (2.0).

Probably the result of putting a DTS stream on an Audio-CD as if it was PCM data, hacking around the Audio-CD specifications :rolleyes:

What does a "standard" CD Player (with no special support for this kind of disc) output on its analog outputs with that disc?

Just loud garbage, I guess...

SeeMoreDigital

13th December 2012, 17:16

Yes, you just hear a load of (white) noise via a CD players 'analogue' outputs...

Kurtnoise

13th December 2012, 17:42

If, however, it is a 2ch PCM WAVE file, as you said earlier, I don't see how this should be possible.
Maybe, you should try this (http://www.movie2digital.at/index.php?page=Thread&threadID=54286)...

SeeMoreDigital

13th December 2012, 18:31

Maybe, you should try this (http://www.movie2digital.at/index.php?page=Thread&threadID=54286)...
I've also just discovered that DTS Parser v2 (http://forum.doom9.org/showthread.php?t=109206) offers the ability to extract the DTS stream out of the .WAV container.

Unfortunately, the extracted DTS stream appears to be slightly corrupted because neither MediaInfo or LameXP is able to read them.

However, UsEac3to v0.9.2 'is able' to read the extracted stream and generate a 6Ch PCM.WAV file, which can then be read by LameXP :D

LoRd_MuldeR

13th December 2012, 20:04

Maybe, you should try this (http://www.movie2digital.at/index.php?page=Thread&threadID=54286)...

Sure, somehow we can create an "upmix" from 2ch data. But that's not what he wants.

Apparently he has a real 5.1 DTS stream, only stored inside a WAVE/RIFF file as "fake" PCM 2ch data :scared:

SeeMoreDigital

13th December 2012, 20:33

Indeed...

For all those interested. Here's a 2Ch Surround Sound DTS sample (http://www.sendspace.com/file/gmcuxn).

Cheers

LoRd_MuldeR

13th December 2012, 22:02

Indeed...

For all those interested. Here's a 2Ch Surround Sound DTS sample (http://www.sendspace.com/file/gmcuxn).

Cheers

Valdec will process that file fine. It detects one error, which probably is the invalid WAVE/RIFF header:
valdec.exe "DTS-stored-as-FakePCM-Wave.wav" -w "Decompressed.wav"

We can also extract the "raw" stream:
sox.exe DTS-stored-as-FakePCM-Wave.wav" -t raw "Raw-Stream.bin"

Still MediaInfo won't recognize it as a DTS stream :rolleyes:

That's not very surprising though, because DTS bitstream errors must be expected here! That's because the Audio-CD was never created for bit-accurate reading. Instead read errors will be "fixed" by interpolating the "missing" data. That of course is done under the assumption that the data, which is defined as PCM data, actually is PCM data. It obviously can't lead to a "reasonable" result with DTS data...

Last but not least, adding support for this kind of file to LameXP is technically impossible, because your file is bit-identical to a proper PCM 2.0 WAVE/RIFF file containing white noise!

(In theory we could test any PCM Wave file by passing it through the DTS decoder and see whether it decodes any valid DTS frames, but that's not really a practicable method)

SeeMoreDigital

13th December 2012, 23:22

Well thanks for trying, it's much appreciated.

At least my request has finally pushed me into finding an alternative (albeit long winded) method of encoding my DTS-CD sources to multi-channel FLAC files.

All I need to do now is find now is a decent 'network capable' hardware player that supports playback of multi-channel FLAC files.

I had hoped that my Onkyo TX-NR609 amp was able to do this but unfortunately they're only played back/decoded as 2Ch :eek:

~bT~

16th December 2012, 23:57

Hi my Lord! Just a lil bug report or maybe user error..

In advanced options--channel mode/sampling rate-- if I tick the 'enforce stereo' option then the encoding fails using an .mp4 file which contains aac audio.

I'm using the latest version.

Cheers for the updates!

LoRd_MuldeR

17th December 2012, 00:13

Motenai Yoda

17th December 2012, 23:39

Maybe you confused DTS with Dolby ProLogic? The latter indeed stores 4 channels (left, right, center, back) in a Stereo signal and the 4 channels can then be restored from the Stereo signal using a ProLogic decoder.
If I'm not wrong dpl can archive up to 5.1 channels in a stereo track.

LoRd_MuldeR

17th December 2012, 23:58

After all it turned out he has a "true" 5.1 DTS stream - only camouflaged as fake PCM 2.0 to hack around the Audio CD specifications.

LoRd_MuldeR

18th December 2012, 01:06

LameXP v4.07 Alpha-7

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2012-12-07)
* Fixed handling of certain characters when passing meta tags on the command-line

apilonte

20th December 2012, 16:24

I have taken audios with my audio recorder, and wanted them to be converted from wav to flac format by LameXP. Since the recorder has taken mono audio tracks I expected the flac files to have a mono track, too. But LameXP, at least with its default settings, gave me stereo tracks. Of course, left and right channel are identical. So the rendered flac file is even bigger than the original wav file. With Audacity (a freeware audio editor), which is using the LAME codecs, too, conversion is done from mono to mono. That's why I hope, LameXP can do it as well and I only didn't press the right button.

My question ist: How can I have LameXP to render flac mono tracks?

Greetings
Heinrich

LoRd_MuldeR

20th December 2012, 16:31

Hello, Heinrich.

First of all, Wave (PCM) to FLAC conversion has nothing to with LAME at all :sly:

Secondly, if a FLAC file with two identical Mono channels comes out twice as big as uncompressed PCM, then that's a good example of how bad (or non-existing) the inter-channel compression of FLAC is ;)

Finally, I am not quite sure how your Mono Wave file can end up as Stereo FLAC file. Can you post your log?

apilonte

20th December 2012, 18:19

Can you post your log?Certainly, if I only knew where to find it. Searching in LameXP's F.A.Q.s I found a slice of text saying "In that case you can double-click on the failed item in order to view the log." But in my case nothing really failed. And if I double-click on the titel just been converted, I get the "meta information", which I don't think will tell you much.

LoRd_MuldeR

20th December 2012, 22:03

You can click on "succeeded" items just as well to show the log ;)

(And here I'm talking about the "Processing" window, not about the main window)

apilonte

20th December 2012, 23:26

This is the log. Input file: channels=1 (line 8); output file: channels=2 (line 39). Hope you see the reason why a second channel has been created.

Heinrich

LameXP v4.06 (Build #1170), compiled on 2012-11-04 at 13:56:05

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

C:/DOKUME~1/Heinrich/LOKALE~1/Temp/d039e52d80114476ab85d728a3a4a0a0/lxp_sox.exe --i "D:/Heinrich/Eigene Musik/MesseRohrdorfProbe.wav"

Input File : 'D:/Heinrich/Eigene Musik/MesseRohrdorfProbe.wav'
Channels : 1
Sample Rate : 44100
Precision : 24-bit
Duration : 01:34:29.92 = 250043400 samples = 425244 CDDA sectors
File Size : 750M
Bit Rate : 1.06M
Sample Encoding: 24-bit Signed Integer PCM

Exited with code: 0x0000

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

--> Number of channels is: 1

C:/DOKUME~1/Heinrich/LOKALE~1/Temp/d039e52d80114476ab85d728a3a4a0a0/lxp_sox.exe -V3 -S --guard --temp . "D:\Heinrich\Eigene Musik\MesseRohrdorfProbe.wav" C:\DOKUME~1\Heinrich\LOKALE~1\Temp\d039e52d80114476ab85d728a3a4a0a0\7548e458743848c29fbdc9cc9c8e4121.wav channels 2

C:\DOKUME~1\Heinrich\LOKALE~1\Temp\d039e52d80114476ab85d728a3a4a0a0\lxp_sox.exe: SoX v14.4.0
C:\DOKUME~1\Heinrich\LOKALE~1\Temp\d039e52d80114476ab85d728a3a4a0a0\lxp_sox.exe INFO formats: detected file format type `wav'
Input File : 'D:\Heinrich\Eigene Musik\MesseRohrdorfProbe.wav'
Channels : 1
Sample Rate : 44100
Precision : 24-bit
Duration : 01:34:29.92 = 250043400 samples = 425244 CDDA sectors
File Size : 750M
Bit Rate : 1.06M
Sample Encoding: 24-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
C:\DOKUME~1\Heinrich\LOKALE~1\Temp\d039e52d80114476ab85d728a3a4a0a0\lxp_sox.exe INFO sox: Overwriting `C:\DOKUME~1\Heinrich\LOKALE~1\Temp\d039e52d80114476ab85d728a3a4a0a0\7548e458743848c29fbdc9cc9c8e4121.wav'
Output File : 'C:\DOKUME~1\Heinrich\LOKALE~1\Temp\d039e52d80114476ab85d728a3a4a0a0\7548e458743848c29fbdc9cc9c8e4121.wav'
Channels : 2
Sample Rate : 44100
Precision : 24-bit
Duration : 01:34:29.92 = 250043400 samples = 425244 CDDA sectors
Sample Encoding: 24-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
C:\DOKUME~1\Heinrich\LOKALE~1\Temp\d039e52d80114476ab85d728a3a4a0a0\lxp_sox.exe INFO sox: effects chain: input 44100Hz 1 channels
C:\DOKUME~1\Heinrich\LOKALE~1\Temp\d039e52d80114476ab85d728a3a4a0a0\lxp_sox.exe INFO sox: effects chain: gain 44100Hz 1 channels
C:\DOKUME~1\Heinrich\LOKALE~1\Temp\d039e52d80114476ab85d728a3a4a0a0\lxp_sox.exe INFO sox: effects chain: channels 44100Hz 2 channels
C:\DOKUME~1\Heinrich\LOKALE~1\Temp\d039e52d80114476ab85d728a3a4a0a0\lxp_sox.exe INFO sox: effects chain: output 44100Hz 2 channels
Done.

Exited with code: 0x0000

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

C:/DOKUME~1/Heinrich/LOKALE~1/Temp/d039e52d80114476ab85d728a3a4a0a0/lxp_flac.exe -7 --channel-map=none -T title=MesseRohrdorfProbe -T "comment=Encoded with LameXP" -T track=1 -f -o "D:\Heinrich\Eigene Musik\MesseRohrdorfProbe (3).flac" C:\DOKUME~1\Heinrich\LOKALE~1\Temp\d039e52d80114476ab85d728a3a4a0a0\7548e458743848c29fbdc9cc9c8e4121.wav

flac 1.2.1, Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007 Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
7548e458743848c29fbdc9cc9c8e4121.wav: WARNING: skipping unknown sub-chunk 'fact' (use --keep-foreign-metadata to keep)
7548e458743848c29fbdc9cc9c8e4121.wav: wrote 425447346 bytes, ratio=0,284

Exited with code: 0x0000

LoRd_MuldeR

21st December 2012, 01:20

Okay, I had a quick look and it turns out that the FLAC encoder class does not have 1 channel (mono) in the list of supported channel counts.

Consequently the input will be up-converted to 2 channels (stereo), before it is sent to the FLAC encoder.

Unfortunately I'm not quite sure whether I omitted 1 channel (mono) intentionally in the list of supported channel counts for FLAC or just forgot it :confused:

Anyway, I will do some more testing when I have more time...

apilonte

21st December 2012, 10:43

I will do some more testing when I have more time...

Thank you. Would be nice if you could find some minutes to look after it.

Heinrich

LoRd_MuldeR

24th December 2012, 22:02

Thank you. Would be nice if you could find some minutes to look after it.

Heinrich

Sorry for the delay, been very busy in the last few days.

I just gave it a try and indeed FLAC will fail to encode from a Mono (1ch) Wave file, so I had disabled "1ch" input for a reason ;)

No idea why FLAC doesn't work with Mono input though...

real.finder

2nd January 2013, 14:03

LameXP v4.05 (Build #1100), compiled on 2012-09-03 at 22:48:43
-------------------------------
C:/Users/SHEKO6~1/AppData/Local/Temp/e85c168fcc05486f9728f8b3be211cdc/lxp_avs2wav.exe D:\sheko6000.2\lossless.avs C:\Users\SHEKO6~1\AppData\Loca\Temp\9\e85c168fcc05486f9728f8b3be211cdc\c45608c1de5845c7b8f83f9a597e4938.wav
avs2wav v1.3 [Aug 16 2011]
by Jory Stone <jcsston@toughguy.net>, updates byLoRd_MuldeR <mulder2@gmx.de>
Input: D:\sheko6000.2\lossless.avs
Output: C:\Users\SHEKO6~1\AppData\Local\Temp\9\e85c168fcc05486f9728f8b3be211cdc\c45608c1de5845c7b8f83f9a597e4938.wav
Checking Avisynth...
Done
Analyzing input file...
Done
Opening output file... Done
[Audio Info]
TotalSamples: 364299776
TotalSeconds: 7590
SamplesPerSec: 48000
BitsPerSample: 16
Channels: 6
AvgBytesPerSec: 576000
Dumping audio data, please wait:
All samples have been dumped. Exiting.
Dump size exceeds 4 GB, cannot save as RIFF/Wave file!
Error while closing output wave file!
Exited with code: 0xFFFFFFFA

LoRd_MuldeR

2nd January 2013, 16:05

Hi, real.finder.

Indeed, as a matter of fact, the maximum size of a RIFF/WAVE file is 4 GB. Do you have any specific question/suggestion? :confused:

BTW: Please use ... tags for pasting logs and other lengthy stuff...

real.finder

2nd January 2013, 16:57

thank you for fast reply

BTW: Please use ... tags for pasting logs and other lengthy stuff...

sorry, I forgot to do that; more like, I see it not necessary because I post the log directly

any way, I think it's avs2wav, avs2wav has a lot of Issues, like it not work if there is no video in avs script

any way I use a big pcm wav file size 4.7 gb directly without an avs script and lamexp work normally

for suggestion, you can use avs2pipemod (http://forum.doom9.org/showthread.php?p=1565165#post1565165) instead of avs2wav, because it work even if there is no video in avs script and more things

for file 4gb and over, it show warning but it work for me

avs2pipemod.exe -wav "x.avs" > "x.wav"

pause

D:\x>avs2pipemod.exe -wav "x.avs" 1>"x.wav"
avs2pipemod[info]: writing 11776.767 seconds of 48000 Hz, 6 channel audio.
avs2pipemod[warning]: audio size over 32bit limit (4GB), clients may truncate audio.
avs2pipemod[info]: finished, wrote 11776.767 seconds [100%].
avs2pipemod[info]: total elapsed time is 60.708 sec.

mediainfo

General
Complete name : D:\x\x.wav
Format : Wave
File size : 6.32 GiB
Duration : 3h 16mn
Overall bit rate mode : Constant
Overall bit rate : 4 608 Kbps

Audio
ID : 0
Format : PCM
Format settings, Endianness : Little
Codec ID : 1
Duration : 3h 16mn
Bit rate mode : Constant
Bit rate : 4 608 Kbps
Channel(s) : 6 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 6.32 GiB (100%)

I wonder how eac3to work for very big file

thank you again

LoRd_MuldeR

2nd January 2013, 17:34

The WAVE/RIFF file format has a size limit of 4 GB. That's a direct consequence of the fact that chunk sizes are defined as 32-Bit integers (unsigned). There is no way around that, except for changing the specifications. That of course wouldn't be WAVE anymore and all programs would have to be updated to support the new format! And indeed, there is the RF64 format that resolves the issue. Only problem: Support for RF64 is pretty much non-existing in audio tools of today! At the same time, some tools use an "ugly" hack to write "normal" WAVE files larger than 4 GB, by simply setting the "size" value to the maximum possible value (~4 GB) and then writing as much data as they have. In other words: They write past the end of the file! Such file obviously is non-standard and broken! Whether any subsequent tool will be able to process the "broken" file is sheer luck.

About avs2wav issues: There may be some other problems in that tool, which I'd have to investigate. But the 4 GB limit is not a bug or limitation of avs2wav. It simply is not possible to write a (correct) WAVE file larger than 4 GB. Unless you have a time machine to go back to the early 90's and convince Microsoft to define the WAVE format with 64-Bit size fields (rather than 32-Bit), nothing can change that... :p

real.finder

2nd January 2013, 17:47

I see, but what about avs2pipemod?

In the end, we will not use the wav file officially, it's just a temporary file within lamexp operations

LoRd_MuldeR

2nd January 2013, 21:02

I see, but what about avs2pipemod?

I'd prefer to fix my avs2wav tool.

In the end, we will not use the wav file officially, it's just a temporary file within lamexp operations

The temp file will be processed by the encoder, so unless all encoders supported/used by LameXP are able to read a "broken" Wave file, creating such a file is pointless.

Also, what if the user selects Wave/PCM output ???

real.finder

2nd January 2013, 22:18

so, what about wave 64 in temporary file within lamexp operations?

and you can make the output in 4gb limit as usual by make the temporary file within lamexp operations only use the fixed avs2wav or avs2pipemod

The choice is yours

thank you again

LoRd_MuldeR

2nd January 2013, 22:29

so, what about wave 64 in temporary file within lamexp operations?

As said before, support for RF64 Wave files is pretty much non-existing in the relevant audio tools. None of the encoders used by LameXP can read this.

LoRd_MuldeR

17th January 2013, 21:33

LameXP v4.07 Beta-1
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2013-01-17/

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-01-17)
* Fixed handling of certain characters when passing meta tags on the command-line

LoRd_MuldeR

25th January 2013, 01:15

LameXP v4.07 Beta-2

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-01-24)
* Fixed handling of certain characters when passing meta tags on the command-line

Atak_Snajpera

25th January 2013, 13:18

Lord_Mulder
I was always wondering why this thread (tool) is not in Audio section? Instead it sits lonely in development section like outcast ;)

SeeMoreDigital

25th January 2013, 13:29

Lord_Mulder
I was always wondering why this thread (tool) is not in Audio section? Instead it sits lonely in development section like outcast ;)
Agreed...

LoRd_MuldeR

25th January 2013, 14:37

I think it could fit into both sub-forums. Originally I opened the thread under "Development", because it was a tool that I was developing myself and I didn't want to imply that this is a "finished" product. I would have put it under "Audio", if I had wanted to discuss about some third-party audio tool. But that wasn't the case. I'm not quite sure whether it should be moved to "Audio" nowadays. But I think moving the thread, after all the time, might confuse some people...

SeeMoreDigital

26th January 2013, 12:56

But I think moving the thread, after all the time, might confuse some people...
I would suppose that all the people who are really interested in LameXP will have subscribed to the thread... So moving it over to the audio section would make no difference to them ;)

LoRd_MuldeR

3rd February 2013, 17:32

LameXP v4.07 Beta-3

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-01-24)
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Fixed handling of certain characters when passing meta tags on the command-line

LoRd_MuldeR

9th February 2013, 20:09

LameXP v4.07 Beta-4

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-02-09)
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line

LoRd_MuldeR

12th February 2013, 22:42

LameXP v4.07 Beta-6
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2013-02-12/

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Minimum supported platform now is Windows XP with Service Pack 3 (download (http://www.microsoft.com/en-us/download/details.aspx?id=24))
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-02-09)
* Updated Valdec decoder to v1.4.0a (2013-02-11), based on latest AC3Filter Tools
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line

real.finder

16th February 2013, 21:34

hi

Any idea about mka support in lamexp?

I use http://sourceforge.net/projects/aud-subsplitter

and the output is mka, for this I have to get it back to origin aac or mp3, etc...

To work with lamexp

thx

LoRd_MuldeR

16th February 2013, 21:42

The problem is that there can be any type of audio in a Matroska file. And all the decoders used by LameXP to decode the various audio formats do not support Matroska files as input.

We would need to demux the audio stream, e.g. via mkvextract (from MKVtoolnox), before decoding, but that currently doesn't fit into the design of LameXP...

manolito

21st February 2013, 00:45

LoRd_MuldeR

21st February 2013, 00:56

I just found out that the latest Beta version refuses to start on my (ancient) machine:

The last line in the console window is "CPU_TYPE_X86_GEN".
The program exits with the message: "Unhandled exception handler invoked, application will exit".

My machine: CPU Intel Celeron Coppermine 1.1 Ghz, MMX and SSE (no SSE2), 576 MB RAM. WinXP Pro SP3, all current updates.

That's interesting. Though I have no idea why that is :confused:

At that point, the application does nothing, but extract the binaries. It does not run any of them yet. And even if we assume that it extracts a "wrong" (unsupported) binary and eventually runs it, only the new process would crash - not the LameXP process itself. So it must be something in the extraction/initialization code...

I also tried to reproduce the behavior the behavior with:
LameXP.exe --force-cpu-no-sse --force-cpu-no-64bit

But works okay for me:
LameXP - Audio Encoder Front-End v4.07 Beta-6 (Build #1246)
Copyright (c) 2004-2013 LoRd_MuldeR <mulder2@gmx.de>. Some rights reserved.
Built on 2013-02-12 at 20:43:58 with MSVC 2012-U1 for Win-x86.

[...]

CPU flags overwritten by user-defined parameters. Take care!

CPU vendor id : GenuineIntel (Intel: 1)
CPU brand string : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz
CPU signature : Family: 6, Model: 15, Stepping: 7
CPU capabilities : MMX: 1, SSE: 0, SSE2: 0, SSE3: 0, SSSE3: 0, x64: 0
Number of CPU's : 4

[...]

Thread is doing something important... Done

Selected CPU is: CPU_TYPE_X86_GEN
Extracting file: aften.i386.exe -> aften.exe
Extracting file: gpgv.exe -> gpgv.exe
Extracting file: elevator.exe -> elevator.exe
Extracting file: dcaenc.exe -> dcaenc.exe
Extracting file: avs2wav.exe -> avs2wav.exe
Extracting file: flac.exe -> flac.exe
Extracting file: gpgv.gpg -> gpgv.gpg
Extracting file: faad.exe -> faad.exe
Extracting file: lame.i386.exe -> lame.exe
Extracting file: mac.exe -> mac.exe
Extracting file: mediainfo.i386.exe -> mediainfo.exe
Extracting file: mpcdec.exe -> mpcdec.exe
Extracting file: mpg123.exe -> mpg123.exe
Extracting file: oggdec.exe -> oggdec.exe
Extracting file: oggenc2.i386.exe -> oggenc2.exe
Extracting file: opusdec.exe -> opusdec.exe
Extracting file: opusenc.exe -> opusenc.exe
Extracting file: refalac.exe -> refalac.exe
Extracting file: shorten.exe -> shorten.exe
Extracting file: sox.exe -> sox.exe
Extracting file: speexdec.exe -> speexdec.exe
Extracting file: tta.exe -> tta.exe
Extracting file: valdec.exe -> valdec.exe
Extracting file: wget.exe -> wget.exe
Extracting file: wma2wav.exe -> wma2wav.exe
Extracting file: wupdate.exe -> wupdate.exe
Extracting file: wvunpack.exe -> wvunpack.exe
All extracted.

Can you please try to find the last build that still worked on your old machine?
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/

Aside from this, I discovered that the latest version of SOX now (kind of) supports large WAV files in the WAVE_FORMAT_EXTENSIBLE format. This is very useful for me because I now can convert large multichannel AAC files to multichannel AC3 with normalization. The following command sequence works: (source is a large (> 5GB) 6ch WAV file)

sox.exe --ignore-length -t wav test.wav -t wav normalized.wav gain -n -1
aften.exe -readtoeof 1 normalized.wav test.ac3

So I see no reason why LameXP shouldn't do this also. Version 4.06 final does not work, even if I use the latest SOX version and add the custom command "-readtoeof 1" to Aften. I had hoped that version 4.07 Beta 6 had corrected this, but unfortunately I could not test it...:devil:

The problem is, we won't know when to pass "--ignore-length". Passing that always doesn't sound like a good idea...

manolito

21st February 2013, 02:06

OK, just tested almost evey 4.07 version starting with Alpha 4. No success, the last working version is 4.06 final. Every version after this shows the same behavior...:scared:

The problem is, we won't know when to pass "--ignore-length". Passing that always doesn't sound like a good idea...

Oh, I do think it is a good idea. From the SOX manual:
--ignore-length
Override an (incorrect) audio length given in an audio file’s header. If this option is given then
SoX will keep reading audio until it reaches the end of the input file.

Just like the Aften "-readtoeof 1" parameter which should always be present, I believe this SOX parameter won't do any harm, even in situations when it is not necessary. Requires some testing...

Cheers
manolito

LoRd_MuldeR

21st February 2013, 02:40

OK, just tested almost evey 4.07 version starting with Alpha 4. No success, the last working version is 4.06 final. Every version after this shows the same behavior...:scared:

Hmm, that's strange. We still need to figure out the exact build number, so I have a chance to figure out what exactly changed.

Version 4.06 Final is build #1170. The next build I uploaded is #1197 (2012-11-24):
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2012-11-24/LameXP-ALPHA.2012-11-24.Release-Static.Build-1197.exe/download

Does that one already fail ???

Oh, I do think it is a good idea. From the SOX manual:

--ignore-length
Override an (incorrect) audio length given in an audio file’s header. If this option is given then
SoX will keep reading audio until it reaches the end of the input file.

Just like the Aften "-readtoeof 1" parameter which should always be present, I believe this SOX parameter won't do any harm, even in situations when it is not necessary. Requires some testing...

We really shouldn't force this behavior unless we absolutely need it, because:
If SoX simply ignores the length, i.e. it continues to reads until it stumbles upon the end of the file, it obviously cannot report progress. That's because if you have read X samples of an "unknown" length, how many percent of the whole thing you have processed? You simply cannot know until you are at 100%. Consequently this would break progress reporting in LameXP, which is a bad thing.
There may be perfectly legal RIFF files that have other (unspecified) data after the audio data in the first "data" chunk. The length info guarantees that we don't read beyond the first "data" chunk. If we blindly ignore the length info, we'll decode that "garbage" at the end of the file. I don't know how common such files are, but we are definitely trading one problem for another here. You could actually argue that WAV/RIFF files bigger than 4 GB are illegal by definition, while files that have additional data after the first "data" chunk definitely are allowed. By definition, all "unknown" chunks are simply ignored (skipped over). So there is a reason why they made it an option.

manolito

21st February 2013, 03:07

Version 4.06 Final is build #1170. The next build I uploaded is #1197 (2012-11-24):
http://sourceforge.net/projects/lame...7.exe/download

Does that one already fail ???

Yes it does. It just pops up the following message:
"Not a debug build. Please unload debugger and try again"
Needless to say that there is no debugger running on my machine.

We really shouldn't force this behavior unless we absolutely need it, because:
If SoX simply ignores the length, i.e. it continues to reads until it stumbles upon the end of the file, it obviously cannot report progress. That's because if you have read X samples of an "unknown" length, how many percent of the whole thing you have processed? You simply cannot know until you are at 100%. Consequently this would break progress reporting in LameXP, which is a bad thing.

I'd much rather do without progress reporting than with the current behavior which is simply annoying. When I try to convert such a file LameXP just does its thing for a long time (these are large files) without any warnings. It reports that it has successfully converted the file, but when I check the output I see that the file is truncated. This is unacceptable.

Cheers
manolito

LoRd_MuldeR

21st February 2013, 03:23

Yes it does. It just pops up the following message:
"Not a debug build. Please unload debugger and try again"
Needless to say that there is no debugger running on my machine.

Now that's sounds like a completely different problem :confused:

So do you only get that issue with that specific build? Is it reproducible? And only your "old" machine or on other machines too?

Also: With which build that issue is gone and you start getting the crash you described earlier?

(BTW: I could also send you a DEBUG build of the latest version, so you might be able to figure out where exactly it crashes...)

The code that would complain about a debugger has not changed at all since 2012-03-26 :eek:

I'd much rather do without progress reporting than with the current behavior which is simply annoying. When I try to convert such a file LameXP just does its thing for a long time (these are large files) without any warnings. It reports that it has successfully converted the file, but when I check the output I see that the file is truncated. This is unacceptable.

Don't forget that you are trying to process an invalid/broken/out-of-specs Wave file. So truncation this is actually the "expected" behavior, regarding the file format specifications ;)

I'm not totally against adding hacks to process such broken files more "gracefully", but only as long as it doesn't cause any bad side effects.

As explained before, always ignoring the length, not only brakes progress reporting (probably), but also could cause other valid files to decode garbage. So it's not really a good idea.

(Best heuristic I could think of in a few minutes is passing "--ignore-length" only for files whose size exceeds 4 GB)

manolito

21st February 2013, 21:45

Now that's sounds like a completely different problem :confused:

So do you only get that issue with that specific build? Is it reproducible? And only your "old" machine or on other machines too?

Also: With which build that issue is gone and you start getting the crash you described earlier?

(BTW: I could also send you a DEBUG build of the latest version, so you might be able to figure out where exactly it crashes...)

OK, those are the results of some heavy testing...

I tried the latest Beta on my Netbook Medion Akoya E1210 (the famous Aldi Netbook), and there were no problems whatsoever. The Atom CPU supports all SSE versions, memory had been upgraded to 2 GB.

On my desktop computer (Celeron Coppermine, only MMX and SSE, 576 MB RAM) all attempts to run the 4.07 versions of LameXP failed. I uninstalled all resident AntiVirus software and made sure that no A/V service was still running. I made the software run with 256 colors, I tried to run it in safe mode, nothing helped.

Version Alpha 4 from 2012-11-24 always gave me the debug build error, and all later versions up to Beta 6 issued the "Unhandled exception handler invoked..." message. And this behavior is reproduceable each and every time.

My conclusion is that XP support in Visual Studio 2012 Update-1 is limited. It's probably not worth your time to debug this.

(Best heuristic I could think of in a few minutes is passing "--ignore-length" only for files whose size exceeds 4 GB)

Yes, I could live with that...

Cheers
manolito

LoRd_MuldeR

21st February 2013, 22:24

OK, those are the results of some heavy testing...

I tried the latest Beta on my Netbook Medion Akoya E1210 (the famous Aldi Netbook), and there were no problems whatsoever. The Atom CPU supports all SSE versions, memory had been upgraded to 2 GB.

On my desktop computer (Celeron Coppermine, only MMX and SSE, 576 MB RAM) all attempts to run the 4.07 versions of LameXP failed. I uninstalled all resident AntiVirus software and made sure that no A/V service was still running. I made the software run with 256 colors, I tried to run it in safe mode, nothing helped.

I think we need a Debug build at this point. Please stay tuned...

Version Alpha 4 from 2012-11-24 always gave me the debug build error, and all later versions up to Beta 6 issued the "Unhandled exception handler invoked..." message. And this behavior is reproduceable each and every time.

I still don't see how this can happen only with specific builds. As said before, the code in question has not changed for ages...

My conclusion is that XP support in Visual Studio 2012 Update-1 is limited. It's probably not worth your time to debug this.

It works fine on all my Windows XP systems. Also I explicitly compile the LameXP "main" program with "/arch:IA32" so it is guaranteed to run fine on systems without SSE/SSE2.

(The default has changed to "/arch:SSE2" in Visual Studio 2012, as has been the case with ICL for a long time)

LoRd_MuldeR

24th February 2013, 02:49

LameXP v4.07 Beta-7

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Minimum supported platform now is Windows XP with Service Pack 3 (download (http://www.microsoft.com/en-us/download/details.aspx?id=24))
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-02-09)
* Updated Valdec decoder to v1.4.0a (2013-02-11), based on latest AC3Filter Tools
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line
* Fixed Keccak library to not crash on systems without SSE/SSE2 support

LoRd_MuldeR

5th March 2013, 22:48

LameXP v4.07 Beta-9

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Minimum supported platform now is Windows XP with Service Pack 3 (download (http://www.microsoft.com/en-us/download/details.aspx?id=24))
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-02-09)
* Updated Valdec decoder to v1.4.0a (2013-02-11), based on latest AC3Filter Tools
* Updated MediaInfo to v0.7.62 (2013-02-22), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line
* Fixed Keccak library to not crash on systems without SSE/SSE2 support

LoRd_MuldeR

17th March 2013, 18:15

LameXP v4.07 Beta-10

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-1
* Minimum supported platform now is Windows XP with Service Pack 3 (download (http://www.microsoft.com/en-us/download/details.aspx?id=24))
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-03-12)
* Updated Valdec decoder to v1.4.0a (2013-03-17), based on latest AC3Filter Tools
* Updated MediaInfo to v0.7.62 (2013-02-22), compiled with ICL 12.1.7 and MSVC 10.0
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line
* Fixed Keccak library to not crash on systems without SSE/SSE2 support
* Fixed LAME algorithm quality selector better match the LAME documentation (link (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#q))

mike20021969

1st April 2013, 16:01

LameXP v4.08 has been released! :)

I still remember 1st April last year ;) :D

boyumeow

5th April 2013, 04:25

I still have that last year released in my computer :p.

LoRd_MuldeR

8th April 2013, 23:51

LameXP v4.07 Beta-12

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-2
* Minimum supported platform now is Windows XP with Service Pack 3 (download (http://www.microsoft.com/en-us/download/details.aspx?id=24))
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-04-08)
* Updated Valdec decoder (2013-04-07), based on AC3Filter Tools v1.0a
* Updated MediaInfo to v0.7.62 (2013-02-22), compiled with ICL 12.1.7 and MSVC 10.0
* Updated Monkey's Audio binary to v4.11 (2013-01-20)
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line
* Fixed Keccak library to not crash on systems without SSE/SSE2 support
* Fixed LAME algorithm quality selector better match the LAME documentation (link (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#q))

LoRd_MuldeR

15th April 2013, 21:18

LameXP v4.07 RC-1

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-2
* Minimum supported platform now is Windows XP with Service Pack 3 (download (http://www.microsoft.com/en-us/download/details.aspx?id=24))
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-04-08)
* Updated Valdec decoder (2013-04-07), based on AC3Filter Tools v1.0a
* Updated mpg123 decoder to v1.15.3 (2013-04-03), compiled with GCC 4.8.0
* Updated MediaInfo to v0.7.62 (2013-02-22), compiled with ICL 12.1.7 and MSVC 10.0
* Updated Monkey's Audio binary to v4.11 (2013-01-20)
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line
* Fixed Keccak library to not crash on systems without SSE/SSE2 support
* Fixed LAME algorithm quality selector better match the LAME documentation (link (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#q))

LoRd_MuldeR

16th April 2013, 23:38

LameXP v4.07 RC-2

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-2
* Minimum supported platform now is Windows XP with Service Pack 3 (download (http://www.microsoft.com/en-us/download/details.aspx?id=24))
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-04-08)
* Updated Valdec decoder (2013-04-07), based on AC3Filter Tools v1.0a
* Updated mpg123 decoder to v1.15.3 (2013-04-03), compiled with GCC 4.8.0
* Updated MediaInfo to v0.7.62 (2013-02-22), compiled with ICL 12.1.7 and MSVC 10.0
* Updated Monkey's Audio binary to v4.11 (2013-01-20)
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line
* Fixed handling of certain characters when renaming output files
* Fixed Keccak library to not crash on systems without SSE/SSE2 support
* Fixed LAME algorithm quality selector better match the LAME documentation (link (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#q))

LoRd_MuldeR

19th April 2013, 21:29

LameXP v4.07 RC-3

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-2
* Minimum supported platform now is Windows XP with Service Pack 3 (download (http://www.microsoft.com/en-us/download/details.aspx?id=24))
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-04-18)
* Updated Valdec decoder (2013-04-07), based on AC3Filter Tools v1.0a
* Updated mpg123 decoder to v1.15.3 (2013-04-03), compiled with GCC 4.8.0
* Updated MediaInfo to v0.7.62 (2013-02-22), compiled with ICL 12.1.7 and MSVC 10.0
* Updated Monkey's Audio binary to v4.11 (2013-01-20)
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line
* Fixed handling of certain characters when renaming output files
* Fixed Keccak library to not crash on systems without SSE/SSE2 support
* Fixed LAME algorithm quality selector better match the LAME documentation (link (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#q))

LoRd_MuldeR

23rd April 2013, 23:50

LameXP v4.07 RC-4

Changes between v4.06 and v4.07:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-2
* Minimum supported platform now is Windows XP with Service Pack 3 (download (http://www.microsoft.com/en-us/download/details.aspx?id=24))
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-04-23)
* Updated Valdec decoder (2013-04-07), based on AC3Filter Tools v1.0a
* Updated mpg123 decoder to v1.15.3 (2013-04-03), compiled with GCC 4.8.0
* Updated MediaInfo to v0.7.62 (2013-02-22), compiled with ICL 12.1.7 and MSVC 10.0
* Updated Monkey's Audio binary to v4.11 (2013-01-20)
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line
* Fixed handling of certain characters when renaming output files
* Fixed Keccak library to not crash on systems without SSE/SSE2 support
* Fixed LAME algorithm quality selector better match the LAME documentation (link (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#q))

LoRd_MuldeR

28th April 2013, 23:23

LameXP v4.07 has been released! :)

Changes between v4.06 and v4.07 [2013-04-28]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-2
* Minimum supported platform now is Windows XP with Service Pack 3 (download (http://www.microsoft.com/en-us/download/details.aspx?id=24))
* Added option to select the "overwrite mode" to advanced options tab
* Added option to filter the log entries on the "processing" dialog (see context menu)
* Added "Up One Level" button to the output folder tab
* Added Opus decoder option to output always at the native sample rate of 48.000 Hz
* Updated Qt runtime libraries to v4.8.4 (2012-11-29), compiled with MSVC 11.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-04-23)
* Updated Valdec decoder (2013-04-07), based on AC3Filter Tools v1.0a
* Updated mpg123 decoder to v1.15.3 (2013-04-03), compiled with GCC 4.8.0
* Updated MediaInfo to v0.7.62 (2013-02-22), compiled with ICL 12.1.7 and MSVC 10.0
* Updated Monkey's Audio binary to v4.11 (2013-01-20)
* Updated SoX to to v14.4.1 (2012-02-09), compiled with ICL 13.0 and MSVC 10.0
* Updated GnuPG to v1.4.13, compiled with GCC 4.7.2
* Updated language files (big thank-you to all contributors !!!)
* Fixed handling of certain characters when passing meta tags on the command-line
* Fixed handling of certain characters when renaming output files
* Fixed Keccak library to not crash on systems without SSE/SSE2 support
* Fixed LAME algorithm quality selector better match the LAME documentation (link (http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#q))

Octo-puss

29th April 2013, 07:51

Yay, new version!

Feature request: could you add an option to save settings to a file instead of registry? I like to carry settings with the program.

LoRd_MuldeR

29th April 2013, 09:37

Huh, the settings always are saved to an INI file :confused:

Octo-puss

29th April 2013, 21:26

Oh? Weird... Either I am blind (very possible), or it's not in the same folder as the program itself.

LoRd_MuldeR

29th April 2013, 21:31

Of course it is not, except when you are running the "portable" edition ;)

LameXP properly supports modern operating systems, which means Windows 2000 and above. Thus it will save configuration files at the one and only correct place: %APPDATA%

(Also note: If you run LameXP in "portable" mode, it is your obligation to make sure that the folder where "LameXP.exe" resides has write permissions)

Octo-puss

1st May 2013, 18:48

Yea that makes perfect sense, however... I copied my LameXP (portable, definitely no installer) to another disk, and then to another PC, ran it, and was immediatelly greeted with accept licence screen (seriously, is the sound in there necessary??), followed by that insane yell generic sound notification. I am absolutely sure I disabled sounds before.

Also - and probably most importantly - there is no ini or any other configuration-implying file in the folder I run it from, and nor does it appear when I change some settings and run LameXP again. The settings ARE saved, though.

edit:
Of course it's what I thought it would be: c:\Users\Administrator\AppData\Local\LoRd_MuldeR\LameXP - Audio Encoder Front-End\config.ini
Keep in mind I never installed the program.

LoRd_MuldeR

1st May 2013, 20:08

How can I use LameXP as a "portable" application?
→ http://lamexp.sourceforge.net/doc/FAQ.html#9fd53558

(And in addition to that, this time I made a "special build" of LameXP that always runs in "probable" mode, on request by a user)

Octo-puss

2nd May 2013, 08:35

Thanks.

LoRd_MuldeR

2nd May 2013, 20:26

Hi MuldeR i want to thank you for this amazing program and if someday the bugs and requests stop i'll be happy if you can implement a way to save the AAC audio only files as m4a. By default the output files are mp4 and its a bit tedious to rename them, but its such a minor thing that you can safely ignore it.

Hi. You are not the first one to ask for this, but I still don't like the idea. That's because I do not like to follow Appel's attempt to force us using a non-standard file extension. And because any halfway decent player application detects the file type by reading/analyzing the file header, rather than hastily making assumptions based on the file name.

See also:
http://en.wikipedia.org/wiki/MPEG-4_Part_14#Filename_extensions

detmek

14th May 2013, 10:12

Hi. You are not the first one to ask for this, but I still don't like the idea. That's because I do not like to follow Appel's attempt to force us using a non-standard file extension. And because any halfway decent player application detects the file type by reading/analyzing the file header, rather than hastily making assumptions based on the file name.

See also:
http://en.wikipedia.org/wiki/MPEG-4_Part_14#Filename_extensions

True. But file association is much easier when video files are .mp4 and audio files are .m4a. That way, for example, MPC-HC will openy video files and foobar2000 will open audio file when you double-click on it.

LoRd_MuldeR

14th May 2013, 13:54

I won't add an option, specifically to output MP4/AAC files with ".m4a" extension.

But I think about extending the rename option to make it possible to overwrite the standard file extension with a user-defined one.

This should be a more general solution, and not specific to the MP4/M4A mess...

mariush

11th June 2013, 05:23

Just a heads up ... they updated the FLAC library last month to 1.3.0, first update in 6 years apparently and the first performed by xiphorg maintainer team: https://xiph.org/flac/changelog.html

SeeMoreDigital

11th June 2013, 09:43

Just a heads up ... they updated the FLAC library last month to 1.3.0, first update in 6 years apparently and the first performed by xiphorg maintainer team: https://xiph.org/flac/changelog.htmlNice one...

Octo-puss

13th June 2013, 08:06

The quality should remain the same though, flac being a lossless codec?... As in, there's no reason to reencode my discs even if this was seemingly pretty big update.

LoRd_MuldeR

13th June 2013, 12:55

The quality should remain the same though, flac being a lossless codec?...

It's lossless. So ;)

(In theory it is still possible that the old version had a bug that sometimes caused "wrong" output that has been fixed now. But I don't see anything like that on the changelog. So there really should be no difference in the quality)

As in, there's no reason to reencode my discs even if this was seemingly pretty big update.

From what I see, they mainly improved the CLI front-end, e.g. to support Unicode file names on Windows and to support Wave64/RF64 files. Also there were a bunch of build fixes. But I don't see anything that says "improved compression by X percent in average", so I don't see a reason to re-encode existing FLAC files.

LoRd_MuldeR

16th June 2013, 14:29

LameXP v4.08 Alpha-2:

Changes between v4.07 and v4.08 [unreleased]:
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0

LoRd_MuldeR

17th June 2013, 23:12

LameXP v4.08 Alpha-3:
http://sourceforge.net/projects/lamexp/files/Snapshots%20%28BETA%29/2013-06-17/

Changes between v4.07 and v4.08 [unreleased]:
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-06-17)
* Fixed a superfluous "beep" sound that appeared on application startup

Dogway

25th June 2013, 05:20

Some suggestions over the span of years of use.

-Remove all the bells & whistles that I need to turn off every time I install a new version (actually main reason I don't update to new version), they make the software look amateurish as well. Minimalism is a plus.
-Remove the autosetted "Encoded with LameXP", it's annoying and extra work for people, it also makes it look as if you had ego issues.
-Allow m4a as AAC container, even it's not speced, it's a pain to have 2 (or 10) files on one folder without knowing whether they are audio or video. Some people me included don't use the same program to play each.
-Expose the real settings for AAC: VBR, TVBR, the Q scale 0-123 or 0-127, etc
-Launch is SLOW, probably because you decompress all the compressed executables. Not only it is slow, but it will wear SSD, and really, was all that necessary? Let the executables rest in a folder.
-Every time I choose an encoder my last used settings are removed.

I know that in an outburst of arrogance you will try to refute each of these and tell NO, NO, NO. But I had to note them down somewhere, and this is the thread. I'm sure I'm not the only one with these little annoyances, but anyway, take it or leave it.

LoRd_MuldeR

25th June 2013, 11:31

First of all I think that feature requests for a software that is offered to you for free could be brought up a bit more kindly.

Especially when you are complaining about program features/shortcomings without contributing any solutions, e.g. in form of patches or cash ... :scared:

But anyway:

-Remove all the bells & whistles that I need to turn off every time I install a new version (actually main reason I don't update to new version), they make the software look amateurish as well. Minimalism is a plus.

I'm not sure what "bells & whistles" is supposed to mean, but if you are referring to the fact that the application settings ate stored separately for each major version of LameXP, then that is by design - since settings between different versions of the program may be incompatible and this way we avoid problems. But how often does a new version major come out? Maybe three times a year. Is it that hard to change a few settings three times a year?

(If you don't want to participate in the development of the software, just don't gab every Alpha/Beta update, wait for the "Final" release - although your settings shouldn't "get lost" within a major version now)

-Remove the autosetted "Encoded with LameXP", it's annoying and extra work for people, it also makes it look as if you had ego issues.

I think some subtle and non-intrusive "promotion" must be allowed.

In case you want to embed an album- or title-specific comment, you have to edit the comment for every album/title anyway, right?

Otherwise, having the default comment embedded doesn't take away anything, does it ???

(If you want to be that ungrateful, you can still change the default comment in the source code. That should be a one-liner, even for the non-programmer)

-Allow m4a as AAC container, even it's not speced, it's a pain to have 2 (or 10) files on one folder without knowing whether they are audio or video. Some people me included don't use the same program to play each.

See here:
http://lamexp.sourceforge.net/doc/FAQ.html#126abc5a

I'm not going to change LameXP to output MP4 files with a wrong extension.

But maybe the existing "auto rename" feature can be extended to cover the file extension as well, which should be sufficient to handle this case for those who really need it.

-Expose the real settings for AAC: VBR, TVBR, the Q scale 0-123 or 0-127, etc

I think those are specific to QAAC. LameXP supports multiple AAC encoders with Nero AAC being the default.

Thus naming the option specifically for QAAC would be a bad idea, obviously.

The settings offered in the GUI are something like a "smallest common denominator" for all supported encoders and they are mapped to the specific settings of the individual encoder internally.

-Launch is SLOW, probably because you decompress all the compressed executables.

If ~2 seconds startup time (with A/V enabled) and almost instantaneously (with A/V disabled) is "slow", well, then 99.9% of all applications are that way.

The program is starting up slower on your systems? Don't shooting the messenger! Get your system fixed...

Most common cause of surprisingly slow performance is slow/buggy A/V software, but I have explained that about a hundred times.

(And I currently have no plans to change the "fully-selfcontained" design of LameXP)

See also:
http://muldersoft.com/temp/lamexp_startup.htm - note that you may need to zoom out a bit

Not only it is slow, but it will wear SSD, and really, was all that necessary? Let the executables rest in a folder.

You must be joking. SSD's are created to write several gigabytes of data every day, for a usage period of ~5 years. And all tests I have seen so far indicate all current SSD's handle this flawlessly.

Actually, in the "torture test" they were unable to "break" any of the SSD's, even when filling them with random data over and over again. Only some SSD's lost some performance over time, probably due to Firmware bugs.

Also your web-browser cache alone probably writes more data to the HDD/SSD within a few minutes of normal usage than starting up LameXP does. Let alone all the other applications, hibernation, etc...

Honestly, I have my SSD for ~3 years now (as system drive) and I use this machine heavily for software development and everything else 24/7. Guess what, in 3 years the "wear out" indicator has decreased from 100% to 98%. Wow!

The super-paranoid user still may move its TEMP directory away from the SSD (system drive) to a classical HDD partition. Just edit %TMP% as desired...

-Every time I choose an encoder my last used settings are removed.

No idea what that is supposed to mean, but probably relates to the first point.

mike20021969

25th June 2013, 17:03

If ~2 seconds startup time (with A/V enabled) and almost instantaneously (with A/V disabled) is "slow", well, then 99.9% of all applications are that way.

The program is starting up slower on your systems? Don't shooting the messenger! Get your system fixed...

2 seconds? Then it has always "launched slow" for me too (around 17 seconds).

Adobe Audition launches in <5 seconds.

My system runs flawlessly. So what sort of things are we supposed to be looking out for to "get fixed"?

LoRd_MuldeR

25th June 2013, 17:11

As you can see here, I get around ~2 seconds with A/V enabled and almost no delay without A/V:
See also:
http://muldersoft.com/temp/lamexp_startup.htm - note that you may need to zoom out a bit

That is on my antiquated Q6600 and using a rather old 40 GB Intel SSD from around 2010. But it seems the SSD doesn't make much of a difference here, since I still get the same speeds when I move %TMP% to my HDD. That's probably because the amount of data written by LameXP is too small and thus still fits into the HDD's write cache.

The most important factor, in my experience, is anti-virus software. Some are unbearably slow! Among those with acceptable speed, in my own experience, are Avira and MSE. But I suggest to try yourself...

(In essence, try to temporarily disable/uninstall everything that hooks into other processes and potentially effects I/O behavior!)

mike20021969

25th June 2013, 17:30

As you can see here, I get around ~2 seconds with A/V enabled and almost no delay without A/V:

Yeah, it looks like AVG does delay that start up time.

Disabling it makes LameXP launch in ~4 seconds :)

Why would it (AVG/AntiVirus) affect LameXP more than other programs?

LoRd_MuldeR

25th June 2013, 17:43

Yeah, it looks like AVG does delay that start up time.

Disabling it makes LameXP launch in ~4 seconds :)

That's consistent with my experience of AVG's slowness. At least they stopped defaming LameXP as being malware :p

Why would it (AVG/AntiVirus) affect LameXP more than other programs?

Hard to say without knowing their code ;)

Maybe a "smart" A/V software remembers the Hash (e.g. Sha-2) of files it already scanned earlier and found to be "clean". So when the same file is encountered again later (even at a different location!), only the Hash needs to be computed (very fast) but the actual "scan" (slow) can be skipped this time. Other A/V software may not be that smart and re-scan the same file over and over again. Just like Sisyphus.

Another possibility: A/V software #1 may be paranoid and scan the file as soon as it's written to the disk, e.g. when the file is about to be closed after the writing operation. Of course this unnecessarily delays the fclose() operation and thus the whole "extraction" process! A/V software #2 might be a bit more intelligent and scan the file only when it actually is accessed for reading, thus not delaying the "extraction" process at all. This will move the "delay" to a later time though. Actually, A/V software #3 might be even smarter: It waits until the file has been written and has been closed, then scans the file in parallel (without blocking anything!). And when the file is access for reading later, it probably has been scanned already.

Last but not least, the pure processing speed of the "scanning" engines used by different A/V programs may simply be different. Some even have to talk to a server for getting the job done...

LoRd_MuldeR

30th June 2013, 02:04

LameXP v4.08 Alpha-4:

Changes between v4.07 and v4.08 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Updated Qt runtime libraries to v4.8.5 RC-1 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-06-17)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup

trunket

30th June 2013, 18:55

Hi LoRd_MuldeR,

Thank you for your great LameXP app. I've been going through this rather long thread looking for some things I'd like to see in LameXP, but since I couldn't find it very well I am taking the risk of mentioning something that has already been brought up before. So that was my disclaimer :)

Anyway, I was wondering if you would mind adding the option to retain encoding settings/options for the various encoders. In the config.ini file (whether using portable or regular version) it does list the settings when I set them, but when I change to encode from, say, MP3 to FLAC, and I go back to MP3, the settings I had previously used are reset again to your/the app's defaults or something. Why is this? To me, if one has a specific encoding option in mind per track, it would be logical to check and change the settings, yes. But if you have found a good overall encoding method for your portable player or PC or what have you, it is far more likely to choose that encoding method again than it is to not use it again. Since with your method (of not saving personal settings when switching between formats) you'd have to change encoding options anyway, it wouldn't negatively impact anyone preferring your method :) So, clearly this speaks in favor of retaining encoding options for each encoder. I hope you understand what I was trying to say :)

Further I applaud you for adding many detailed options for encoding into your app (like all the channel modes for LAME, etc.) which is something I much appreciate. I always keep a local copy of your app around (I use several quality frontends) and made a little icon for my own LameXP app folder:
http://img835.imageshack.us/img835/1622/r86n.png (http://imageshack.us/photo/my-images/835/r86n.png/)

EDIT: I noticed I couldn't turn off/unselect checking for (Beta) updates in your latest development release. Is this by design? I'd like to turn it off for my local copy, regardless of it being a development release. My reasoning is (not unlike with the encoding settings argument) that if one wants to try developmental releases, one should understand there will be subsequent (and more stable) releases. I guess I just have this 'thing' about having to be able to turn off online checking with any app ;)

LoRd_MuldeR

30th June 2013, 19:41

Anyway, I was wondering if you would mind adding the option to retain encoding settings/options for the various encoders. In the config.ini file (whether using portable or regular version) it does list the settings when I set them, but when I change to encode from, say, MP3 to FLAC, and I go back to MP3, the settings I had previously used are reset again to your/the app's defaults or something. Why is this? To me, if one has a specific encoding option in mind per track, it would be logical to check and change the settings, yes. But if you have found a good overall encoding method for your portable player or PC or what have you, it is far more likely to choose that encoding method again than it is to not use it again. Since with your method (of not saving personal settings when switching between formats) you'd have to change encoding options anyway, it wouldn't negatively impact anyone preferring your method :) So, clearly this speaks in favor of retaining encoding options for each encoder. I hope you understand what I was trying to say :)

It's not that the settings get reset when you change the encoder. It's simply that LameXP currently does not store the encoder settings (encoding mode + bitrate/quality value) separately for each encoder. Instead it's stored only once! So if you switch from MP3 to, e.g., FLAC, then move the bitrate/quality slider and finally switch back to MP3, your MP3 settings have changed too. Same goes with the encoding mode (CBR vs. ABR vs. VBR). I could change the program to maintain the state separately for each encoder, but this will require quite some work...

EDIT: I noticed I couldn't turn off/unselect checking for (Beta) updates in your latest development release. Is this by design? I'd like to turn it off for my local copy, regardless of it being a development release. My reasoning is (not unlike with the encoding settings argument) that if one wants to try developmental releases, one should understand there will be subsequent (and more stable) releases. I guess I just have this 'thing' about having to be able to turn off online checking with any app ;)

Yes, it is by design. With stable versions you can choose whether you want to check for updates in the "default" or the "beta" channel. Only the latter will find pre-release (Beta) updates, while the former is restricted to new stable versions. However, once you have a beta version installed, it only makes sense to check the "beta" channel for updates. That's because beta versions always are newer than the latest stable release, so you can never find any updates for beta versions in the "default" channel. Note that when there currently are no new beta versions available (e.g. shortly after a release), then both, the "default" and "beta" channel, simply point to the latest stable release. It's also during that "phase" when old beta versions (older than the current stable release) will update to the current stable release...

trunket

30th June 2013, 21:29

So if you switch from MP3 to, e.g., FLAC, then move the bitrate/quality slider and finally switch back to MP3, your MP3 settings have changed too. Same goes with the encoding mode (CBR vs. ABR vs. VBR). I could change the program to maintain the state separately for each encoder, but this will require quite some work...
OK, so I would think it'd be a great thing to save the settings if possible. All the other frontends I've used do retain such settings even when switching between formats, and I think *most* people are looking for this or expecting this. But I understand if it is hard to do. When I looked at your config.ini file (I was using the portable version you made) I was seeing things like: AdvancedOptions\LAME\ChannelMode=0 so I was thinking maybe do the same for just LAME\VBR\ etc. so when switching back to LAME from another format, it will pick up the settings from there again.

Yes, it is by design. With stable versions you can choose whether you want to check for updates in the "default" or the "beta" channel. Only the latter will find pre-release (Beta) updates, while the former is restricted to new stable versions. However, once you have a beta version installed, it only makes sense to check the "beta" channel for updates. That's because beta versions always are newer than the latest stable release, so you can never find any updates for beta versions in the "default" channel. Note that when there currently are no new beta versions available (e.g. shortly after a release), then both, the "default" and "beta" channel, simply point to the latest stable release. It's also during that "phase" when old beta versions (older than the current stable release) will update to the current stable release...

OK, I understand then ;)

LoRd_MuldeR

9th July 2013, 22:29

LameXP v4.08 Alpha-6:

Changes between v4.07 and v4.08 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Encoder settings (RC mode + bitrate/quality) are now stored separately for each encoder
* Updated Qt runtime libraries to v4.8.5 RC-1 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-06-17)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup
* Fixed Ogg Vorbis quality modes "-1" and "-2" (they were clipped to "0" before)
* Fixed a bug that could cause the output directory to be reset mistakenly

LoRd_MuldeR

12th July 2013, 23:09

LameXP v4.08 Beta-1:

Changes between v4.07 and v4.08 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Encoder settings (RC mode + bitrate/quality) are now stored separately for each encoder
* Updated Qt runtime libraries to v4.8.5 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1.x and Opus-Tools to v0.1.6 (2013-07-10)
* Updated MediaInfo to v0.7.64 (2013-07-05), compiled with ICL 13.1 and MSVC 10.0
* Updated GNU Wget binary to v1.13.4 (2011-09-17)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup
* Fixed the Ogg Vorbis quality modes "-1" and "-2" (those were clipped to "0" before)
* Fixed a bug that could cause the output directory to be reset mistakenly

rhaz

23rd July 2013, 09:28

Hi. Latest stable version fails at decoding MP3s to WAVs, I tried now the latest 30-day beta version and it works fine. Also Drag&Drop do not work in both stable and beta on Win8x64. When dragging .mp3 onto the box or program window, simply nothing happens.

manolito

23rd July 2013, 12:38

Works fine here (WinXP SP3)...:confused:

Latest stable version 4.07. MP3 to WAV no problems, does not matter if normalization is checked or not. Drag and Drop also working fine here.

I suppose there is something going on about your system...

Cheers
manolito

rhaz

23rd July 2013, 16:55

Also 'Browse Output File Location' doesn't work. And XP and Win8 are a bit different I'd say, not same. So if it works on XP it doesn't mean anything.

LoRd_MuldeR

23rd July 2013, 20:52

Hi.

MP3 to Wave works fine me. So what exactly does not work for you? And what does your log say? :confused:

As for Drag&Drop, works fine for me on Windows XP, Windows 7 and Windows 8.

However be sure you do not launch LameXP with elevated rights, as this would "block" Drag&Drop (besides that it is not needed at all).

"Browse Output File Location" also works for me just fine on Windows 8...

mastrboy

23rd July 2013, 21:00

Can lamexp handle m2ts (pcm, blu ray files) for input?
So tired of writing cmd scripts for eac3to :P

LoRd_MuldeR

23rd July 2013, 21:05

Can lamexp handle m2ts (pcm, blu ray files) for input?

Nope. You'll need to demux the audio stream with something like tsMuxeR (http://www.videohelp.com/tools/tsMuxeR) first.

SeeMoreDigital

23rd July 2013, 21:06

I got a new build today 4.08 Beta-2 dated 2013-07-23.... ;)

LoRd_MuldeR

23rd July 2013, 21:08

I got a new build today 4.08 Beta-2 dated 2013-07-23.... ;)

So? :confused:

LoRd_MuldeR

24th July 2013, 18:03

LameXP v4.08 Beta-2:

Changes between v4.07 and v4.08 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Encoder settings (RC mode + bitrate/quality) are now stored separately for each encoder
* Updated Qt runtime libraries to v4.8.5 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1-beta and Opus-Tools to v0.1.6 (2013-07-22)
* Updated MediaInfo to v0.7.64 (2013-07-05), compiled with ICL 13.1 and MSVC 10.0
* Updated GNU Wget binary to v1.13.4 (2011-09-17)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup
* Fixed the Ogg Vorbis quality modes "-1" and "-2" (those were clipped to "0" before)
* Fixed a bug that could cause the output directory to be reset mistakenly

LoRd_MuldeR

21st August 2013, 19:29

LameXP v4.08 RC-1:

Changes between v4.07 and v4.08 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Encoder settings (RC mode + bitrate/quality) are now stored separately for each encoder
* Updated Qt runtime libraries to v4.8.5 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1-beta and Opus-Tools to v0.1.6 (2013-07-22)
* Updated MediaInfo to v0.7.64 (2013-07-05), compiled with ICL 13.1 and MSVC 10.0
* Updated GnuPG to v1.4.14 (2013-07-25), compiled with GCC 4.8.1
* Updated GNU Wget binary to v1.13.4 (2011-09-17)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup
* Fixed the Ogg Vorbis quality modes "-1" and "-2" (those were clipped to "0" before)
* Fixed a bug that could cause the output directory to be reset mistakenly

LoRd_MuldeR

25th August 2013, 16:46

LameXP v4.08 RC-2:

Changes between v4.07 and v4.08 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Encoder settings (RC mode + bitrate/quality) are now stored separately for each encoder
* Updated Qt runtime libraries to v4.8.5 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1-beta and Opus-Tools to v0.1.6 (2013-07-22)
* Updated MediaInfo to v0.7.64 (2013-07-05), compiled with ICL 13.1 and MSVC 10.0
* Updated GnuPG to v1.4.14 (2013-07-25), compiled with GCC 4.8.1
* Updated GNU Wget binary to v1.13.4 (2011-09-17)
* Updated language files (big thank-you to all contributors !!!)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup
* Fixed the Ogg Vorbis quality modes "-1" and "-2" (those were clipped to "0" before)
* Fixed a bug that could cause the output directory to be reset mistakenly
* Implemented "natural order" string comparison/sorting, using strnatcmp() by Martin Pool

LoRd_MuldeR

4th September 2013, 10:33

LameXP v4.08 has been released :)
http://lamexp.sourceforge.net/ | http://lamexp.berlios.de/

Changes between v4.07 and v4.08 [2013-09-04]:
* Upgraded build environment to Microsoft Visual Studio 2012 with Update-3
* Encoder settings (RC mode + bitrate/quality) are now stored separately for each encoder
* Updated Qt runtime libraries to v4.8.5 (2013-05-31), compiled with MSVC 11.0
* Updated FLAC encoder/decoder to v1.3.0 (2013-05-27), compiled with ICL 13.0
* Updated Opus encoder/decoder libraries to v1.1-beta and Opus-Tools to v0.1.6 (2013-07-22)
* Updated MediaInfo to v0.7.64 (2013-07-05), compiled with ICL 13.1 and MSVC 10.0
* Updated GnuPG to v1.4.14 (2013-07-25), compiled with GCC 4.8.1
* Updated GNU Wget binary to v1.13.4 (2011-09-17)
* Updated language files (big thank-you to all contributors !!!)
* Fixed a potential deadlock during startup when %TMP% points to an invalid folder
* Fixed a superfluous "beep" sound that appeared on application startup
* Fixed the Ogg Vorbis quality modes "-1" and "-2" (those were clipped to "0" before)
* Fixed a bug that could cause the output directory to be reset mistakenly
* Implemented "natural order" string comparison/sorting, using strnatcmp() by Martin Pool

Octo-puss

4th September 2013, 19:33

Please don't forget to update the portable build as well :P

LoRd_MuldeR

4th September 2013, 20:27

I have uploaded a new "portable" build.

Octo-puss

5th September 2013, 13:10

Thank you!

Motenai Yoda

17th September 2013, 16:28

Hi! With the 4.0.8 final-1 it doesn't recognize fhgaac (I'm on w8).

Also as Dogway has claimed required, why don't change the slider's scale for each aac encoder? (now I don't know how it works, but if is by lists of possibly values as I think, should be quite simple to add an if, or a switch case, statements to change them.)

byez

LoRd_MuldeR

25th September 2013, 11:51

Hi! With the 4.0.8 final-1 it doesn't recognize fhgaac (I'm on w8).

Works for me :confused:

Are you 100% sure all the required DLL files are in the correct place?

http://i.imgur.com/ixsJm0dl.jpg (http://i.imgur.com/ixsJm0d.jpg)
http://i.imgur.com/jWaFHXel.jpg (http://i.imgur.com/jWaFHXe.jpg)

Also as Dogway has claimed required, why don't change the slider's scale for each aac encoder? (now I don't know how it works, but if is by lists of possibly values as I think, should be quite simple to add an if, or a switch case, statements to change them.)

Surely, this would be possible. But it would be bad designed, since it adds even more complexity to the GUI code.

I rather prefer to keep the GUI code agnostic of the specific AAC encoder and, instead, keep the details in the individual encoder class.

The ultimate goal is to keep the GUI code completely agnostic of any encoder. But this will require a new "configuration options" interface to be implemented by the encoder classes, so the GUI can query the supported encoding modes, the supported bitrates as well as the supported VBR levels from the selected encoder - rather than having all that knowledge hardcoded in the GUI code.

But this will be a rather massive redesign of the inner workings...

Motenai Yoda

29th September 2013, 22:49

LoRd_MuldeR

30th September 2013, 13:18

edit2: I didn't mean in the gui code, but a method that change that list into an "AACEncodersWrapper" class (or something like this) in the way that each "XXXEncodersWrapper" class can manage XXX lists internally.

But now that it's switched from naac to fhgaac, the slider's scale for VBR mode has yet changed. 0.o

Sorry, I have no idea what you mean :confused:

LoRd_MuldeR

2nd October 2013, 15:44

there are the exact same files, maybe different versions? I took from your pack and last winamp installer.

edit: now I make a clean reinstall with all new files, and work.

edit2: I didn't mean in the gui code, but a method that change that list into an "AACEncodersWrapper" class (or something like this) in the way that each "XXXEncodersWrapper" class can manage XXX lists internally.

But now that it's switched from naac to fhgaac, the slider's scale for VBR mode has yet changed. 0.o

Sorry, I have no idea what you mean :confused:

Anyway, today I started refactoring all the encoder-specific code out of the GUI code:
http://pastie.org/private/gpbkatoeas1kdtmk5te92g

One of my most productive days was throwing away 1,000 lines of code - Ken Thompson

LoRd_MuldeR

7th October 2013, 12:25

LameXP v4.09 Alpha-1:

Changes between v4.08 and v4.09 [unreleased]:
* Improved internal encoder API, so each encoder can define its own configuration options
* Complete overhaul of the file analyzer, resulting in up to 2.5x faster file import speed

I have almost finished moving the encoder-specific options out of the GUI code. Now each encoder can expose its own configurations options, through the new encoder API. This also means that now each of the three AAC encoders can have its own separate configurations options! Furthermore, the file analyzer has been rewritten completely. The new code is much faster. In my test, the time for importing about 1000 files decreased from 116 seconds to 46 seconds (about 2.5x faster).

Sparktank

7th October 2013, 16:11

Thanks for the update. :)

It's been a long time since I used this so this should definitely be fun to play with.

LoRd_MuldeR

9th October 2013, 17:27

FWIW, I made made a short clip that shows LameXP v4.08 vs. LameXP v4.09 while importing the very same set of 1160 files:
http://www.mediafire.com/download/o5ggo5xmlwowbue/lamexp_importManyFiles_v408_VS_v409.zip

(Note that these runs were captured one after another and stacked together afterwards. Also, I have a feeling that without the capturing software, the difference is even larger)

mike20021969

9th October 2013, 18:03

LameXP v3.08 vs. LameXP v3.09

Old version numbers?

LoRd_MuldeR

9th October 2013, 18:18

Whoops. Should be 4.xx, of course ;)

EDIT: Fixed!

LoRd_MuldeR

13th October 2013, 00:56

LameXP v4.09 Alpha-2:

Changes between v4.08 and v4.09 [unreleased]:
* Improved internal encoder API, so each encoder can define its own configuration options
* Complete overhaul of the file analyzer, resulting in up to 2.5x faster file import speed
* Updated mpg123 decoder to v1.16.0 (2013-10-06), compiled with GCC 4.8.1
* Various bugfixes and code improvements

LoRd_MuldeR

19th October 2013, 00:03

LameXP v4.09 Alpha-3:

Changes between v4.08 and v4.09 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 RTM
* Improved internal encoder API, so each encoder can define its own configuration options
* Complete overhaul of the file analyzer, resulting in up to 2.5x faster file import speed
* Updated mpg123 decoder to v1.16.0 (2013-10-06), compiled with GCC 4.8.1
* Updated GnuPG to v1.4.15 (2013-10-05), compiled with GCC 4.8.1
* Various bugfixes and code improvements

LoRd_MuldeR

25th October 2013, 02:49

LameXP v4.09 Alpha-4:

Changes between v4.08 and v4.09 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 RTM
* Complete overhaul of the file analyzer, resulting in up to 2.5x faster file import speed
* Reworked the application initialization code, resulting in notably faster startup speed
* Improved file analyzer to retain the original ordering of files imported from a playlist
* Improved internal encoder API, so each encoder can define its own configuration options
* Updated mpg123 decoder to v1.16.0 (2013-10-06), compiled with GCC 4.8.1
* Updated GnuPG to v1.4.15 (2013-10-05), compiled with GCC 4.8.1
* Various bugfixes and code improvements

LoRd_MuldeR

28th October 2013, 03:40

LameXP v4.09 Alpha-5:

Changes between v4.08 and v4.09 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 RTM
* Complete overhaul of the file analyzer, resulting in up to 2.5x faster file import speed
* Reworked the application initialization code, resulting in notably faster startup speed
* Improved file analyzer to retain the original ordering of files imported from a playlist
* Improved internal encoder API, so each encoder can define its own configuration options
* Updated mpg123 decoder to v1.16.0 (2013-10-06), compiled with GCC 4.8.1
* Updated GnuPG to v1.4.15 (2013-10-05), compiled with GCC 4.8.1
* Various bugfixes and code improvements

SeeMoreDigital

28th October 2013, 16:58

It sure does start up faster now :)

LoRd_MuldeR

1st November 2013, 03:50

LameXP v4.09 Alpha-6:

Changes between v4.08 and v4.09 [unreleased]:
* Upgraded build environment to Microsoft Visual Studio 2013 RTM
* Complete overhaul of the file analyzer, resulting in up to 2.5x faster file import speed
* Reworked the application initialization code, resulting in notably faster startup speed
* Improved file analyzer to retain the original ordering of files imported from a playlist
* Improved internal encoder API, so each encoder can define its own configuration options
* Improved dropbox widget, including proper multi-monitor support
* Updated mpg123 decoder to v1.16.0 (2013-10-06), compiled with GCC 4.8.1
* Updated GNU Wget binary to v1.14.0 (2012-08-05), compiled with GCC 4.8.1
* Updated GnuPG to v1.4.15 (2013-10-05), compiled with GCC 4.8.1
* Various bugfixes and code improvements

Interestingly, I noticed that the previous WGet binary would crash on my old WinXP laptop, while it did not crash on any of my WinXP VM's (that I normally use for testing) or on any of my other machines. So I compiled a new binary from the sources. To my surprise, the new binary still causes an unhanded exception. It's easy to reproduce in GDB (see here (http://i.imgur.com/h8938zV.png)). And after I finally managed to make a debug binary of WGet (it's not straight forward to make MinGW link against the debug MSVCRT), I realized that the problem originates from a "hack" in WGet where they close the same file descriptor twice, ending up in MSVCRT calling CloseHandle() with an invalid handle value. Now, does anybody have an idea why this normally doesn't trigger a crash (just fails silently), except on one specific system? I guess this is the awesomeness of "undefined behavior" caused by issuing Syscalls with invalid handle values... :rolleyes:

real.finder

3rd November 2013, 11:40

hi LoRd_MuldeR :)

Simple suggestion about the wav 4G issue

a wav file (the temporary one) can be split by size (every 4G or 3.9G ((or something else)) becomes section) if the file is larger than 4g before input in Encoders

Then the files that were encoded separately will be merged into the final file in the end

-----

And another thing, if I encoded flac 5.1 into ogg in lamexp, the order of channels will be different

thanks :)

LoRd_MuldeR

3rd November 2013, 14:27

Simple suggestion about the wav 4G issue

a wav file (the temporary one) can be split by size (every 4G or 3.9G ((or something else)) becomes section) if the file is larger than 4g before input in Encoders

Then the files that were encoded separately will be merged into the final file in the end

Not possible in reality for various reasons:

(1) For this to work, every decoder we use would have to support an option to split "ultralarge" Wave files. AFAIK, currently none of the decoders we use supports this option.

(2) Even if we could resolve the first point, we would still need to join the encoded files. This is easy with a "raw" format like MP3, since we can simply do a binary concatenation. But it is very difficult with containers like MP4 or OGG, where you have global headers and stuff. For those formats we would either have to implement our own MP4/OGG muxer or use something like MP4Box.

(3) Even if we could resolve the second point, there's another problem: Most compressed audio formats introduce some padding at the beginning and/or the end of the audio stream. So if you encode the audio in several "chunks" (separate input Wave files), then every chunk gets this padding. Now, if you join together those chunks later, you will get a short "silence" at every junction point, because of the padding.

Proper solution for this would be using Wave64 files instead of RIFF/WAV. But that won't be possible until all (or at least most) of the encoders/decoders start supporting Wave64 :rolleyes:

(I think at this moment, only ValDec from AC3Filter Tools is able to create Wave64 files, all other tools don't even read them)

And another thing, if I encoded flac 5.1 into ogg in lamexp, the order of channels will be different

This would indicate either the Ogg decoder creates a Wave file with "wrong" (non-standard) channel mappings or the FLAC encoder assumes a "wrong" (non-standard) channel mappings when reading Wave files.

In any of those cases, this would have to be fixed either in OggDec or in FLAC. There's not much I can do here...

(Well, I could try to implement a workaround by re-ordering the channels in the intermediate Wave file using SoX, but that would require yet another processing step. And it's an ugly hack)

real.finder

3rd November 2013, 16:10

thank you for reply :)

about wav, I wonder if using pipe between the decoder and encoder will override the 4g issue

Example with an avs:-

avs2pipemod -wav "script.avs" | venc -q4 - "OutputFileName.ogg"

pause

or

avs2pipemod -wav=16bit "script.avs" | venc -q4 - "OutputFileName.ogg"

pause

Example without avs:-

oggdec -o "input.ogg" | sox -S -t wav - -t wav - --norm=-0.5 | venc -q4 - "OutputFileName.ogg"

pause

or

oggdec -o "input.ogg" | sox -S -t wav - -t wav - gain -n -0.5 | venc -q4 - "OutputFileName.ogg"

pause

--------

and about the flac and the channels, if I use bassAudioSource in avs the channels order will be ok, that mean the problem in the decoder

thank you :)

LoRd_MuldeR

3rd November 2013, 16:20

Using pipes would resolve the 4 GB issue, indeed. This has been discussed before.

The problem is: What is the exact format we send over the pipe? Is it "raw" PCM data? If so, how do we tell the second process the PCM format (channel count, sample rate, sample format)?

And if we do not send "raw" PCM, do we send a "fake" non-standard Wave header in front of the PCM data? Does every application support/recognize this?

In practice we would have to check for each pair of applications whether they can communicate via pipe - and how it can be done. For N applications this makes N^2 pairs to check...

Dogway

18th November 2013, 12:04

More bashing:
Disc Number metadata is not passed through (probably other tags as well)
Loading mini-windows looks 90's software
We have talked this before but auto-comment tag "Encoded by LameXP" is there to crap things out, I'm aware of your narcissism, but that is counter-productive, some people put valuable data on comments, and you not only wipe it out like nothing, but force everybody to do one added step to set the comments tag to nothing. If you want more exposure you should first take my advices for good and improve the software.

LoRd_MuldeR

18th November 2013, 14:41

Disc Number metadata is not passed through (probably other tags as well)

It is not technically possible to simply "pass through" meta tags. Please forget about that idea! If you re-encode an audio file, any meta tags will just disappear - unless you explicitly detect them from the original input file, remember them in a special data structure and explicitly re-embed them into the re-encoded file. This all doesn't happen by itself!

Now, LameXP supports at least 20 different input formats (decoders) and 8 different output formats (encoders). Consequently, retaining the meta tags is not trivial at all. That's especially because every encoder, decoder and file formats uses their own types of meta tags. There is no universal standard for meta tags that everybody in the world has agreed on. Instead, things have evolved over the decades. And often quite differently.

The good thing about standards is: There are so many to choose from...

Therefore, the "internal" meta data model of LameXP, i.e. the meta info that LameXP will "remember" for each file, has been designed to be a "smallest common denominator" for what is supported by all (most) file formats that LameXP deals with. And indeed, this was mostly inspired by ID3 v1. This doesn't mean that the "internal" meta data model of LameXP is perfect or that it will be fixed forever. But right now I don't have plans to change it.

Loading mini-windows looks 90's software

No idea what you are referring to, but feel free to elaborate... :rolleyes:

We have talked this before but auto-comment tag "Encoded by LameXP" is there to crap things out, I'm aware of your narcissism, but that is counter-productive, some people put valuable data on comments, and you not only wipe it out like nothing, but force everybody to do one added step to set the comments tag to nothing. If you want more exposure you should first take my advices for good and improve the software.

As I probably have explained earlier, I won't change the default value for the "comment" tag. You can change the "comment" value easily on the "meta data" tab at any time, just not the default value.

As long as this software is provided for free, I don't have to justify this decision. If you don't like it, you can file a feature request. In contrast to "more bashing", a polite feature request might actually motivate the developer to consider your change request. Anyway, you really cannot expect that your feature requests will be accepted right away. Different people have different opinions. And, in the end, it's the developer who has to make the decision which feature he likes or doesn't like in his software. Or which feature he can implemented with reasonable effort (and which ones he can not implement). There's no reason to be miffed if one of your requests gets discarded or postponed.

If you disagree with the developer and still would like the software to be changed in your way, you have two possibilities:

Get coding! As long as the software is provided as OpenSource, you are given the freedom to modify the software according to your own needs. Time to make something out of that ;)
If your coding skills are insufficient for a simple modification or you simply are too lazy, you can still hire a developer to implement the desired modification for you.