Monkey 1 Ultimate Talkie Edition (released)

md5 · Post by **md5** » Sun Apr 03, 2011 10:33 pm

IANAL, but I don't think there's a problem with redistributing msvcr71.dll - it's a redistributable library. Unfortunately, I don't think there's an easy way to obtain it now, as the redistributable patches that MS provides are for VS2005 (i.e. VC++ 8.0) and 2008 (i.e. VC++ 9.0). Windows 2000 and later versions should include that file by default.

Which tool needs msvcr71.dll?

LogicDeLuxe · Post by **LogicDeLuxe** » Sun Apr 03, 2011 11:27 pm

md5 wrote:Which tool needs msvcr71.dll?

Apparently, scummpacker.exe is using it. It is a compiled python tool.
Are you sure that Windows 2000 and later always have this included? In that case, I could easily ditch it, as Windows XP is the minimum requirement for this to work anyway.

That leaves xWMAEncode.exe, which is part of the DirectX SDK, a package some hundreds MB in size.

md5 · Post by **md5** » Mon Apr 04, 2011 6:23 am

The problem with this file is explained a bit in a Python thread, e.g.:
http://osdir.com/ml/python.py2exe/2005-05/msg00064.html

In essence, the file's status is dubious. Theoretically, it should be "ok" to distribute it if you own VS 2003. But limiting people from downloading this is silly. It's really easy to obtain newer versions of this DLL (for VC++ 8.0 and newer) from Microsoft, but this version is obsolete now. Googling around, it looks like it's included in .NET 1.1 SDK, but that's a hefty 100MB+ download.

This page gives more insight:

The MSVCRT.LIB that ships with 32 bit compiler Visual C++ Toolkit 2003 dynamically links to MSVCR71.DLL which is not present in a freshly installed Windows XP system. MSVCR only appears after some software package that needs it such as Adobe Acrobat Reader is installed.

fingolfin · Post by **fingolfin** » Mon Apr 04, 2011 7:45 am

LogicDeLuxe wrote:
md5 wrote:Which tool needs msvcr71.dll?
Apparently, scummpacker.exe is using it. It is a compiled python tool.

Well, in that case, wouldn't it be possible to compile it into a single static linked binary, without an external dependency on a non-system DLL ?

(Rant: I never quite understood why on Windows it seems to be normal for apps to have to install all kinds of DLLs, including one for the "C run time", before you can run them. Shouldn't the CRT part of the OS, not each app? Weird).

md5 · Post by **md5** » Mon Apr 04, 2011 10:11 am

fingolfin wrote:
LogicDeLuxe wrote:
md5 wrote:Which tool needs msvcr71.dll?
Apparently, scummpacker.exe is using it. It is a compiled python tool.
Well, in that case, wouldn't it be possible to compile it into a single static linked binary, without an external dependency on a non-system DLL ?

Unfortunately, no. This is a Python script, and it is compiled into a Windows binary using py2exe, so this is an issue with Python itself. It would still be possible to ask people to install Python, but I believe that a single DLL file makes things easier...

(as for your rant: at least Windows doesn't have the RPM hell that RPM-based distros have)

LogicDeLuxe · Post by **LogicDeLuxe** » Mon Apr 04, 2011 10:49 am

md5 wrote:it looks like it's included in .NET 1.1 SDK, but that's a hefty 100MB+ download.

Is it by any chance also included in dotnetfx35.exe? That one comes and is required by MISE, so I could be sure it exists.

Still, xWMAencode is the more inconvenient file. It is included in DXSDK_Jun10.exe which is a ridiculous 571 MB.

bobdevis · Post by **bobdevis** » Mon Apr 04, 2011 10:53 am

md5 wrote: at least Windows doesn't have the RPM hell that RPM-based distros have)

You call that DLL-Hell I believe. Hasn't happened to me lately but it used to be really unfunny with some early non backwards-compatible versions of DirectX.

md5 · Post by **md5** » Mon Apr 04, 2011 11:03 am

bobdevis wrote:
md5 wrote: at least Windows doesn't have the RPM hell that RPM-based distros have)
You call that DLL-Hell I believe. Hasn't happened to me lately but it used to be really unfunny with some early non backwards-compatible versions of DirectX.

It doesn't matter. Please don't change the subject and don't turn this into a never ending *nix vs. Windows thread...

Back to the original subject: I don't think it's a problem to distribute msvcr71.dll. If you aren't comfortable with its distribution, you can provide a link to download the file instead (e.g. the Python binary). But it *should* be safe to include both the DLL and the tool (though, as I said, IANAL).

fingolfin · Post by **fingolfin** » Mon Apr 04, 2011 1:40 pm

LogicDeLuxe wrote:Still, xWMAencode is the more inconvenient file. It is included in DXSDK_Jun10.exe which is a ridiculous 571 MB.

You only need it to decode WMA files to WAVE, and then later encode the WAVE file to Ogg or flac, right? If so, why not use ffmpeg or some other open source tool for that purpose? Using ffmpeg might even allow you to directly convert from WMA to FLAC/Ogg Vorbis. So you could also replace sox by this.

clone2727 · Post by **clone2727** » Mon Apr 04, 2011 2:25 pm

fingolfin wrote:
LogicDeLuxe wrote:Still, xWMAencode is the more inconvenient file. It is included in DXSDK_Jun10.exe which is a ridiculous 571 MB.
You only need it to decode WMA files to WAVE, and then later encode the WAVE file to Ogg or flac, right? If so, why not use ffmpeg or some other open source tool for that purpose? Using ffmpeg might even allow you to directly convert from WMA to FLAC/Ogg Vorbis. So you could also replace sox by this.

AFAIK, no open source program supports xWMA.

fingolfin · Post by **fingolfin** » Mon Apr 04, 2011 7:55 pm

Hm, really? According to the page you linked, "xWMA is a subset of the Windows Media Audio (WMA) Professional compression format." -- and FFmpeg claims to support WMA Professional.
But of course maybe xWMA really is not just a subset. Or maybe the FFmpeg support for WMA Pro is incomplete. It's a bit difficult to find information about the exact support level for WMA in FFmpeg, too :/. I guess only by trying it can we find out.

PS: And also rockbox support WMA Pro, see http://www.rockbox.org/wiki/NewWMAAudioCodecs

clone2727 · Post by **clone2727** » Mon Apr 04, 2011 8:17 pm

fingolfin wrote:But of course maybe xWMA really is not just a subset. Or maybe the FFmpeg support for WMA Pro is incomplete. It's a bit difficult to find information about the exact support level for WMA in FFmpeg, too :/. I guess only by trying it can we find out.

It also doesn't help that searching for "FFmpeg xWMA" in Google has this forum post on its first page already. But, yes, it would make sense if FFmpeg (or libav, or whatever people want to call it now) did support it already...

fingolfin · Post by **fingolfin** » Mon Apr 04, 2011 10:17 pm

FFmpeg is FFmpeg; libav is a fork.

clone2727 · Post by **clone2727** » Mon Apr 04, 2011 10:41 pm

fingolfin wrote:FFmpeg is FFmpeg; libav is a fork.

Yes, it was my lame attempt at a joke

fingolfin · Post by **fingolfin** » Tue Apr 05, 2011 8:00 am

clone2727 wrote:
fingolfin wrote:FFmpeg is FFmpeg; libav is a fork.
Yes, it was my lame attempt at a joke

Damn, and I fell for it! Ah well, I already have the reputation of having no sense of humor, so this just underlines it

Back to topic: It would be really interesting to know if ffmpeg can decode these files or not. So if somebody can test it and report the findings, that would be most interesting. By the way, if it is *not* supported, I think the ffmpeg guys might be interested to learn about it, maybe they would even be interested in adding support.