FFSoX Player plug-in released

pbelkner · 15th June 2010, 07:27

FFSoX Player is a Winamp plug-in based on the FFmpeg (http://www.ffmpeg.org/) and SoX (http://sox.sourceforge.net/) libraries. Using FFmepg almost all multimedia files, both audio and viseo, may be played, including but by far not restricted to H.264 and VP8. Audiophile sound processing, e.g. replay gain, is provided using high quality 32 bit SoX algorithms and dithering.

Home: http://in-ffsox.sourceforge.net/
Download: http://sourceforge.net/projects/in-ffsox/files/

pbelkner · 27th June 2010, 17:30

Just released v0.2:

http://sourceforge.net/projects/in-ffsox/files/

What's new?

Now with installer.
Now with (minimal) FFmpeg for playing OGG (both Vorbis audio and Theora video) and WebM (Vorbis audio and VP8 video, the latest one from Google)

Would be glad to get some feedback from you.

Peter

Koopa · 27th June 2010, 17:38

Had a quick look and it's looking good, but I may ask for some thing, though.

1. Is there any reason, why it doesn't use Winamp's global playback settings for ReplayGain on 5.5x installs? It's a bit annoying, that you have to switch Winamp's RG settings off, especially since I'd use your plugin for video files only.

2. Are there any plans to make it localizable via the 5.5+ language system?

pbelkner · 27th June 2010, 19:00

There are two reasons why I currently don't use the global Replay Gain setting:

1. I simply don't know how to access it.
2. I fear that possibly Replay Gain is applied two times, the first time by the plug-in and the second time by Winamp itself. But possibly I'm wrong.

Localization is planed.

Peter

Koopa · 27th June 2010, 19:55

1. I'm sure a dev can help you and explain how to use that API, which hopefully automatically prevent 2.

Disabling Winamp's RG options isn't ideal. I'll ask if a dev could reply here.

DrO · 27th June 2010, 20:04

from in2.h

PHP Code:


			
// Set this if you adjusted volume for replay gain. For tracks with no replay gain metadata then you
// should clear this flag UNLESS you handle "non_replaygain" gain adjustment yourself then keep it.
#define IN_MODULE_FLAG_REPLAYGAIN 8

which is used in the UsesOutputPlug member of In_Module if you're doing your own RG processing so it'll make Winamp not do its own version. though i'm really struggling to see what advantage this has over Winamp's own plug-ins.

-daz

pbelkner · 27th June 2010, 21:21

Thanks a lot!

Quote:

though i'm really struggling to see what advantage this has over Winamp's own plug-ins.

One of the core ideas for this plug-in is to use SoX (http://sox.sourceforge.net/) at 32 bit for all DSP including replay gain, up-sampling and dithering. Hopefully in the near future I will explain this a bit deeper on the plug-in's home page. I run this plug-in myself for about half a year and I'm convinced that this is a very good idea.

Peter

pbelkner · 28th June 2010, 11:52

"IN2.H" has the following:

PHP Code:


			
#define IN_MODULE_FLAG_USES_OUTPUT_PLUGIN 1

// By default, Winamp assumes that your input plugin wants to use Winamp's EQ, and doesn't do replay gain

// if you handle any of these yourself (EQ, Replay Gain adjustments), then set these flags accordingly

#define IN_MODULE_FLAG_EQ 2 // set this if you do your own EQ

#define IN_MODULE_FLAG_REPLAYGAIN 8 // set this if you adjusted volume for replay gain

                                                                        // for tracks with no replay gain metadata, you should clear this flag 

                                                                        // UNLESS you handle "non_replaygain" gain adjustment yourself

#define IN_MODULE_FLAG_REPLAYGAIN_PREAMP 16 // use this if you queried for the replay gain preamp parameter and used it

If I understand it right, according to http://forums.winamp.com/showthread.php?postid=2014534 the plug-in's init() function should have the folling:

PHP Code:


			
in.UsesOutputPlug |= IN_MODULE_FLAG_REPLAYGAIN;

in.UsesOutputPlug |= IN_MODULE_FLAG_REPLAYGAIN_PREAMP;

This should prevent Winamp from appling RG and RG preamp twice. Is this correct?

How do I query the global RG and RG preamp settings ("IN2.H" at least mentiones that it should be possible.)

Peter

DrO · 29th June 2010, 08:39

i believe what i posted and what you've found as the other flag defined should be enough to block it (though i'm sure i was told somewhere that it needs to be re-added at other times as well but i'd have to check that).

as for reading the RG settings, you'd need to use the agave_api_config service from the sdk though if you're overriding and using your own implementation then there isn't really a need to query it.

-daz

pbelkner · 3rd July 2010, 17:27

Added setting the RG flags from "IN2.H" to both init() and play().

As it seems global RG settings may be left switched on now without affecting the plug-in.

On the other hand I have no idea how to access global RG settings. It would be nice to know because it would avoid requiring the user to set and synchronize RG settings on two places.

Last but not least: FFSoX Player plug-in runs perfectly with WA 5.58

Home: http://in-ffsox.sourceforge.net/
Download: http://sourceforge.net/projects/in-ffsox/files/

pbelkner · 4th July 2010, 19:22

Got a feature request on SourceForge this morning:

Quote:

So far winamp lacks any resampling plugin that resamples audio. This is useful for people who have the soundblaster audigy series, which forces audio playback in 48Khz, and any audio not at that resolution will get resampled by the APU, which is horrible in the audigy series. Besides that, some others, although having good cards, may prefer resampling techniques done in software instead of hardware. As far as I know, one of the more prominent resamplers for foobar2000 was based on SoX algorithms, so I hope that this could be implemented in this plugin as well. Thank You

In response I've created v0.3 making almost all SoX resampling options available to the user. For details cf.

Download: http://sourceforge.net/projects/in-f...3.exe/download

pbelkner · 14th July 2010, 12:32

Have a feature request at Sourceforge:

Quote:

This plugin doesn't seem to support files with unicode naming? I would like to see it implemented if possible, although another alternative is simply to rename the files myself, it might be more practical to add unicode support to the plugin so that it can be used by people from different countries.

Quote:

with winamp's default input plugins, im able to play my songs which has
japanese characters in the file name, for example. when i switched over to
your plugin, i can't play them anymore

For opening the file I'm using the fn parameter from the Play() method as defined in "IN2.H":

PHP Code:


			
int (*Play)(const in_char *fn);        // return zero on success, -1 on file-not-found, some other value on other (stopping winamp) error

Can somebody tell whether there is something special with japanese characters?

pbelkner · 14th July 2010, 12:54

Quote:

Can somebody tell whether there is something special with japanese characters?

I think I've figured it out myself. Possibly I should define UNICODE_INPUT_PLUGIN.

Koopa · 14th July 2010, 14:09

If you run for example a German Operating system, and try to play a file with Japanese chars in the filename or in the tag, it will only show ???? instead of the correct chars.

If I can remember, there are a lot more places, where you can directly use a Unicode Call/API. E.g. there is a Unicode API for getting metadata, there is an Unicode API for the Winamp transcoder etc.

Also if you plan localization support in future, you should use Unicode as well, otherwise special chars or umlauts will only show ???? in the preferences.

The plugin simply should support Unicode where possible, ANSI based plugins and programs have no future.

But a plugin dev can give you a better, more complex description.

Some Links:

http://en.wikipedia.org/wiki/Unicode
Winamp 5.55 SDK
Winamp Development Forum

pbelkner · 14th July 2010, 14:57

Thanks a lot, Koopa.

As already mentioned I propably should recompile the plug-in with UNICODE_INPUT_PLUGIN defined. But this causes a follow-up problem. With UNICODE_INPUT_PLUGIN defined the in_char type is no longer a 8 bit ordinary char but a 16 bit wchar_t. This conflicts with the methods for opening a file in the SoX library as well as in the FFmpeg library. Both expect ordinary 8 bit char.

Browsing through the internet I found the following solution:

Get the classical DOS path from the given Windows path via GetShortPathNameW()
Simply cast down the wchar_t to oridnary char hoping that all japanese characters are removed from the DOS path.

In order to test this I wrote the following simple program:

PHP Code:


			
#include <stdio.h>

#include <windows.h>



wchar_t buf1[MAX_PATH];

wchar_t buf2[MAX_PATH];

char buf3[MAX_PATH];



OPENFILENAMEW ofn = {

    .lStructSize = sizeof(ofn),

    .hwndOwner = NULL,

    .lpstrFilter = L"All Files (*.*)\0*.*\0",

    .lpstrFile = buf1,

    .nMaxFile = MAX_PATH,

    .Flags = OFN_EXPLORER | OFN_FILEMUSTEXIST | OFN_HIDEREADONLY,

    .lpstrDefExt = L"txt",

};



int WINAPI WinMain(HINSTANCE hinstance,

            HINSTANCE hprevinstance,

            LPSTR lpcmdline,

            int ncmdshow)

{

    AllocConsole();

    freopen("conin$", "r", stdin);

    freopen("conout$", "w", stdout);

    freopen("conout$", "w", stderr);



    if (GetOpenFileNameW(&ofn))

    {

        // Do something useful with the filename stored in szFileName 

        wchar_t *p2=buf2;

        char *p3=buf3;

        FILE *f;



        // Convert unicode long path into unicode short path.

        // Hopefully the short path doesn't contain japanese special

        // characters.

        GetShortPathNameW(buf1, buf2, sizeof buf2);



        // Convert unicode short path into ASCII short path.

        while (*p2)

            *p3++=*p2++;



        *p3=0;

        f=fopen(buf3, "rb");

        fprintf(stdout, "\"%s\": %s.\n", buf3,

                f?"file opened":"error opening file");



        if (NULL!=f)

            fclose(f);

    }



    fprintf(stdout, "\nHit any key ... ");

    fflush(stdout);

    fgetc(stdin);



    return 0;

}

Can somebody from Japan compile and run this program? Is this program able to open files with japanese characters in their names?

Koopa · 14th July 2010, 15:08

Quote:

GetShortPathNameW()

Yes the 'W' indicates a Unicode call. I hope you find more Unicode calls in the SDK I linked to.

Quote:

Can somebody from Japan compile and run this program? Is this program able to open files with japanese characters in their names?

Yes, but a Japanese user can have trouble with German umlauts. If you make the plugin fully Unicode, you can open media files, independent from the used OS language/code page.

A pretty shitty example, I as a German user want to listen a Japenese soundtrack of an Anime (for example MP3 files).

If the input plugin (an mp3 decoder input plugin in that case) support ANSI only, the Songticker, the ATF string in the playlist will all show ???? instead of the correct chars.

There are tons of specific Unicode calls and you really should use them where possible.

The only downside, is that Unicode only works on NT+ based Systems. For Win9x based system you must use this, for basic Unicode support:

http://www.microsoft.com/downloads/d...displaylang=en

But, I doubt that Win 9x support is really a worthwhile goal.

PS: I highly doubt, that the guy who made the request was a Japanese user. Furthermore I bet he is a user, who speaks a language with latin letters and only wants to listen/watch files, with Japanese chars.

pbelkner · 14th July 2010, 15:36

Quote:

Originally Posted by Koopa

Yes, but a Japanese user can have trouble with German umlauts. If you make the plugin fully Unicode, you can open media files, independent from the used OS language/code page.

Thats of course true. The difference between german umlauts and japanese characters seems to be that german umlauts are defined in the classical 8 bit range but the japanese chracters only in the extended 16 bit range, i.e. german umlauts don't cause this problem (I already tried it). A test with some file having japanese characters in its name would be very useful.

Is it possible to upload the test program's compiled version to the forum? It would make it potential testers a bit easier.

Koopa · 14th July 2010, 15:44

The WavPack decoder plugin had massive trouble even with German umlauts in the dialogs, when we tested it for the Essentials Pack. So German umlauts can fail on English, ANSI based applications as well.

And we are not only talking about eastern languages, Arabic languages, Greek etc neither won't be shown on English/German systems, if the plugin is ANSI only.

I send you a PM with a media file.

You can upload zip attachments, I can modify your first post and add an attachment if you want.

pbelkner · 14th July 2010, 16:01

Quote:

Originally Posted by Koopa

You can upload zip attachments, I can modify your first post and add an attachment if you want.

Would be great.

pbelkner · 14th July 2010, 16:18

Second try to upload "test.zip" containing "test.c", "test.exe", and "Makefile".

pbelkner · 25th July 2010, 14:37

What's new?

Enabled seeking (depends on whether the corresponding FFmpeg format supports it).
Made switching on/off the gain effect's limiter available in configuration dialog.
Resolved some issues which caused the plug-in to crash in case of unsupported codecs.