▲

[saga]

...which would result in way more code than importing UNMO3_GetVersion and you'd still have to differentiate between several DLL versions, so is a worse solution. Please go away with your senseless suggestions, you are not being helpful at all.

[kode54]

Or you could supply your own copy of the library so you always link against the version you developed for, assuming redistribution is compatible with the licenses of unmo3 and your program or library.

[Ian @ un4seen]

One minor problem, I had to typedef or define DWORD myself. I decided to import stdint.h and typedef it from uint32_t.

Oops. I had intentionally avoided using Windows types in the UNMO3.H header previously, but forgot to so in this update. I have now changed it to use "unsigned" instead of "DWORD".

It's kinda unfortunate that old library versions will crash when using the new UNMO3_Decode specification, though, not sure if anything in the interface could be changed to avoid that. Otherwise the host programm will have to check the DLL version, I guess.

Yep, you could use UNMO3_GetVersion to check that the appropriate DLL version is loaded. You don't necessarily need to call it though; it was introduced at the same time as the UNMO3_Decode "flags" parameter, so its presence alone is enough to confirm the UNMO3_Decode signature

Anyway, good to hear that the update is working well so far. Let me know if any problems do crop up.

[saga]

Yeah, I guess that's the most sensible approach for now. Luckily, calling the new DLL from an old program expecting the two-parameter signature (without flags) still works, so that's at least something.

[kode54]

A fairly minor problem I've discovered. Or at least it's minor because I can work around it rather than letting my users crash frequently.

Namely, the library does not appear to be thread safe. Unpacking more than one MO3 at a time from different threads results in crashes.

I can work around this by dynamically loading the module and copying it around to random names in the temporary folder when I need more than one instance at a time.

[Ian @ un4seen]

That's strange, as the library should be thread-safe. I quickly tried reproducing the problem with the following code, but it never happened.

Code SelectExpand

#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
#include "unmo3.h"

void *buf;
unsigned len;

DWORD WINAPI threadproc(void *p)
{
while (1) {
void *buf0=buf;
unsigned len0=len;
int r=UNMO3_Decode(&buf0, &len0, 0);
printf("%d: unmo3=%d\n", (int)p, r);
if (!r) UNMO3_Free(buf0);
}
return 0;
}

int main(int argc, char **argv)
{
FILE *f;
if (argc<2) return 0;
f=fopen(argv[1], "rb");
if (!f) return 0;
len=filelength(fileno(f));
buf=malloc(len);
fread(buf, len, 1, f);
fclose(f);
CreateThread(0, 0, threadproc, (void*)0, 0, 0);
CreateThread(0, 0, threadproc, (void*)1, 0, 0);
getchar();
return 0;
}

Can you produce the problem with something that?

[kode54]

I am using version 2.4.0.3, and I am also calling LoadLibrary/GetProcAddress/FreeLibrary from each thread which unpacks an MO3. It was the original way I dealt with bundling the library in my component's directory before the player started adding the components' own directories to the DLL search path in turn while each component is being loaded. I suppose I could change that now.

[Ian @ un4seen]

I am using version 2.4.0.3

Ah, I think that would explain it. Thread-safety was added in 2.4.0.4. To ensure that the correct DLL version is loaded, you could check for the presence of the UNMO3_GetVersion function, which was also added in 2.4.0.4.

[kode54]

The problem isn't that someone is providing the wrong version, since I bundle my own copy. I just neglected to update the component. Let me take care of that right now.

[Dr. Fiemost]

Is this library supposed to support mp3 samples? I get mostly silent output from the mo3 I've tried.

[saga]

You're right, MP3 sample support seems to be broken in the latest version indeed!
Here's an example file to demonstrate the problem.
I also noticed that a previous version of unmo3.dll (dated 2011) had a problem with this particular MO3 file; the belltree sample had some silence in the loop part of the sample. This doesn't happen in the latest XMPlay however, so it's probably already fixed.

[Ian @ un4seen]

Oops! There were some changes in the MP3 decoder, which the UNMO3 code hadn't been updated for yet. Here's an update that should sort it...

   www.un4seen.com/stuff/unmo3lib.zip

Let me know if it still gives you any trouble.

[saga]

Yup, that seems to fix the problem. Thanks for the quick fix!

[Dr. Fiemost]

Thanks for the fix, works fine so far.

[saga]

Since libopenmpt can use the unmo3 library as a "plug-in" to decode MO3 files, a couple of Android libopenmpt users have asked if this feature could be made on Android as well. Ian, would it be possible to port the library to Android as well?

[CasualBoy]

I am second to Saga proposal.
I would like to see Mo3 supported in my Android phone.

[Ian @ un4seen]

Since libopenmpt can use the unmo3 library as a "plug-in" to decode MO3 files, a couple of Android libopenmpt users have asked if this feature could be made on Android as well. Ian, would it be possible to port the library to Android as well?

I'll look into building an Android version this week. Have you already implemented the dynamic library loading for Android in your code? I recall that is a bit tricky/messy because the app's "lib" folder isn't in Android's library search path, so you need to provide the full path, which is tricky/messy to get in native code.

I would like to see Mo3 supported in my Android phone.

If you happen to just want to play MO3 files, that is possible with the BASS library.

[saga]

We didn't have a look yet, but I'll try to ask the people who're interested in the feature if they can help out. My own experience with Android is rather limited.

[Ian @ un4seen]

OK. An Android version of the unmo3 library has now been added...

   www.un4seen.com/stuff/unmo3lib.zip

It's untested so far, so let me know if you have any trouble with it. As I mentioned, loading it in native code may be tricky due to the issue of getting the full path. It'll probably be simplest to load it from Java first, and then the native code shouldn't need the full path to access it.

Code SelectExpand

System.loadLibrary("unmo3");


[haspor]

Hi,

I tested the library and it seems to be produce too much decoded data. Decode function returned success but the filesize became over 15MB (encoded size is 473484 bytes). The real decoded size is around 4.7MB. Also the filesize and decoded contents change if you decode the same data several times in a row. Tested on Android x86.