libmpg123-0.dll

[Wodd]

In what revision was the requirement for libmpg123-0.dll removed for loading MP3 samples. I believe that I have found a bug and am trying to figure out when it first occurred. So far, I have found that it is between revisions 5400 and 5500. Specifically, since a revision later than revision 5400, but at or before revision 5500, the improper length is displayed for samples. I noticed that revision 5400 requires the presence of the libmpg123-0.dll in the root directory of the executable. But, revision 5500 does not. That is why I am wondering if the bug is somehow related to the removal of the requirement for libmpg123-0.dll. If you would like to test it yourself, you can download The Numeric Mc¿Rib to do so. The proper length is 9,991,296 samples. The displayed length should be 9,990,768 samples.

[Saga Musix]

The requirement was never removed, but OpenMPT added sample decoding through Media Foundation codecs was added at that time, which can serve as a fallback solution for MP3 sample decoding if mpg123 is not present. The difference you observe most probably comes from the fact that Media Foundation does not support LAME Gapless headers, while mpg123 does. If you want LAME headers to be respected, you should put the mpg123 library into the same directory as mptrack.exe, just like you did before.
This is not a problem with OpenMPT, hence I am moving this topic out of the development corner.

[Wodd]

Do I need an updated version of the libmpg123-0.dll file? I have a copy of that file that is said to be from March of 2,014. Perhaps it is corrupt somehow and needs to be replaced. It does reside in the same location as the OpenMPT executable. But, I am guessing that the LAME headers are not being respected. Even in revision 8578, the file to which I linked shows a length of 9,990,768 samples, not 9,991,296 samples, as it should. Although, in revision 5400, when I tried to load the MP3 file without libmpg123-0.dll in the directory, I received an unknown format dialog. When I copied the DLL into the directory with the executable, the sample loaded and the correct length was displayed. When I tested revision 5500, I don't think that I copied the DLL into the directory with the executable. I noticed that, upon looking at revision 8578 again, there is a file named openmpt-mpg123.dll in the bin folder. When I run the executable within that folder, the correct sample length is displayed. Perhaps that replaced the libmpg123-0.dll file or perhaps libmpg123-0 is used only for writing MP3 files. Although, that might be what the openmpt-lame.dll file is for as well. I am not sure. Incidentally, when I copied the file from the source code folder into my main directory, the correct sample length is displayed.

[manx]

Current 1.27.xx.xx versions of OpenMPT do in fact come with libmpg123 bundled. Thus there is no need to download libmpg123 separately any more. The old file names (like libmpg123-02.dll) are not even supported any more, and only the bundled openmpt-mpg123.dll will be used. See https://forum.openmpt.org/index.php?topic=5708.msg44105#msg44105 and https://wiki.openmpt.org/Manual:_Samples.

[Wodd]

I suppose that the same is probably true for a file named openmpt-lame.dll (I believe that it was). I suppose that file supersedes lame_enc.dll. Is that correct? Do I need only those 2 files now? In fact, are all of the files replaced now? I have the following files in my OpenMPT root directory:

• lame_enc.dll
• MIDI Input Output.dll
• OpenMPT_SoundTouch_f32.dll
• PluginBridge32.exe
• PluginBridge64.exe

Do I need those anymore? Are there equivalent, updated versions of them in the later revisions of the code? My current revision is revision 8578.

[manx]

Lame_enc.dll is deprecated since ages (about 1.23.01.00). Either use libmp3lame (see https://wiki.openmpt.org/Manual:_Saving_and_exporting#Format), or if you are compiling yourself, just use the openmpt-lame.dll which gets built automatically.

[manx]

Lame_enc.dll support was removed completely in r8099.

[manx]

• MIDI Input Output.dll

is built directly into mptrack.exe these days.

[Saga Musix]

Wodd: This forum is the wrong place to discuss the difference in length (528 samples) when using different codecs to decompress the MP3 file. OpenMPT is not involved in this process and both results are technically correct.

[Wodd]

both results are technically correct.

Based on what you mentioned about the headings before, that makes sense. Although, it did look odd to see the absent samples, given that the audio sample quantity is directly related to the duration (in seconds) of the audio file mathematically.
Based on Manx's posts, it looks like I no longer need MIDI Input Output.dll and lame_enc.dll (which appears to be completely defunct anyway). I will remove those, replace the LAME file, and keep the SoundTouch and PluginBridge files. Thanks

[Saga Musix]

Based on what you mentioned about the headings before, that makes sense. Although, it did look odd to see the absent samples, given that the audio sample quantity is directly related to the duration (in seconds) of the audio file mathematically.

The MP3 format, without any extensions, cannot save streams of arbitrary length - an MP3 stream always has a length that is a multiple of 1152 (9,991,296 MOD 1152 = 0). In this particular example, the original audio content was only 9,990,768 samples long, but since that is not divisible by 1152, the audio content has to be padded with silence to a multiple of 1152 samples. The LAME headers tell the decoder how much of this silence needs to be removed in order to get the original intended length of the audio. But LAME headers are not an official part of the MP3 standard so both resulting lengths are technically correct.