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

View Full Version : LameXP v4.21 Final · Build #2382 (2023-12-29)

Pages : 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

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