FFSoX Player plug-in released

[pbelkner]

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]

Just released v0.2

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]

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]

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]

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]

from in2.h

// 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]

Thanks a lot!

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]

"IN2.H" has the following:

#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:

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]

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]

FFSoxPlayer v0.2.1 released

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]

v0.3 released

Got a feature request on SourceForge this morning:

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.

• http://in-ffsox.sourceforge.net/#sox
• http://in-ffsox.sourceforge.net/#sox-resample

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

[pbelkner]

Feature Request: Unicode Support

Have a feature request at Sourceforge:

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.

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":

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]

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]

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]

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:

1. Get the classical DOS path from the given Windows path via GetShortPathNameW()
2. 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:

#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?