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

[LoRd_MuldeR]

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

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

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

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

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

[LoRd_MuldeR]

LameXP Test-Build r1636 :eek:

[lethedoom]

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

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

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

[LoRd_MuldeR]

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

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

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

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

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

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

[mariush]

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

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

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

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

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

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

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

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

-

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

[LoRd_MuldeR]

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

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

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

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

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


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

[LoRd_MuldeR]

LameXP Test-Build r1646 :eek:

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

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

[schiff1108]

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

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

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

[LoRd_MuldeR]

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

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

[Octo-puss]

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

[schiff1108]

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

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

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

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

[LoRd_MuldeR]

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

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

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

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

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

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

[LoRd_MuldeR]

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

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

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

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

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

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

[LoRd_MuldeR]

LameXP Test-Build r1655:

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

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

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

[Techie007]

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

[LoRd_MuldeR]

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

Hi, Techie007.

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

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

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

[BoosterPack]

Hello,

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

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

[LoRd_MuldeR]

Hello,

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

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

Hello, BoosterPack.

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

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

[Techie007]

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

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

[mike20021969]

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

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

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

Thanks.

[LoRd_MuldeR]

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

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


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

That's a completely different topic! ;)

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

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

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

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

[LoRd_MuldeR]

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

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

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

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

[mike20021969]

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

I will do that during next release install.

Would that remove the registry entries as well?

[LoRd_MuldeR]

Would that remove the registry entries as well?

It is supposed to, yes.

[mike20021969]

It is supposed to, yes.
Thanks :cool:

[Techie007]

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

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

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

{modOpusGUI.bas}

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

frmOpusGUI.Show
End Sub
______________________________

{frmDelagte.frm}

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

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

{frmOpusGUI.frm}

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

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

{modOpusGUI.bas}

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

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

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

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

[LoRd_MuldeR]

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

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

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

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

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

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

[Techie007]

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

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

[LoRd_MuldeR]

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

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

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

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

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

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

[BoosterPack]

Hello, BoosterPack.

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

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

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

[LoRd_MuldeR]

I needed to run the program as administrator.

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

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

[schiff1108]

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

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

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

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

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

[justonce01]

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

[LoRd_MuldeR]

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

Reading educates :)

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

[LoRd_MuldeR]

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

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

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

[BoosterPack]

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

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

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

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

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

[LoRd_MuldeR]

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

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

[jpsdr]

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

[LoRd_MuldeR]

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

Because it has not been updated yet :p

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

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

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

[foxyshadis]

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

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

[jpsdr]

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


That's finaly all that matters.
:thanks:

[justonce01]

Reading educates :)

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

Got it. Thanks.

[Octo-puss]

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

[LoRd_MuldeR]

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

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

[Octo-puss]

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

[LoRd_MuldeR]

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

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

[Octo-puss]

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

[LoRd_MuldeR]

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

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

[manolito]

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


Cheers
manolito

[LoRd_MuldeR]

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

Done.