WinAMP Plugin Cuts Songs

[phistuck]

Whenever I enable the plugin (I am using the "redux" version of WinAMP as requested), two things happen -

• The song starts from the fifteenth second in the timeline. The timeline (and elapsed time) shows the fifteenth second and continues from there. It is playing the song from its beginning, so nothing is actually cut from the beginning of the song, but it is not very nice. I can live with it, however...
• Songs end some (fifteen?) seconds too early. They simply get clipped or cut off.

I was using "Allow 24-bit" and got an error message whenever I tried to play anything. I stopped using it and I successfully played songs, but then those problems happen.

[lordmulder]

Dynamic Audio Normalizer uses a pretty large filter "window". The default filter size is 31 frames, and the default frame size is 500 milliseconds. So, overall, the default filter size is about 15 seconds. Before the Dynamic Audio Normalizer can start returning "processed" audio samples to the application (e.g. Winamp), it needs to read "ahead" the required number input samples to fill the internal buffer (filter window).

Actually, the Winamp plugin-API does allow me to read "ahead" input samples without returning any process samples (yet) – which explains why »nothing is actually cut from the beginning«. Still, Winamp doesn't seem to deal well with DSP plugins that use a large internal buffer. For example, the "timeline" seems to reflect the number of samples that have been pumped into the DSP chain, not the number of samples that have actually popped out of the DSP chain. Also, as you have noticed, Winamp doesn't seem to properly "flush" the DSP chain at the end of the track. Instead, it simply discards the "pending" samples.

Because I think that the Dynamic Audio Normalizer plugin implements things as good as possible with the current Winamp plugin-API, and because the development of Winamp is dead, chances for a fix are highly improbable. But if you have any suggestions on how things could be improved, just let me know...

Regards.

[phistuck]

This renders the whole plugin useless. I suggest that you remove it from the readme. No one wants to listen to truncated songs.

Also, the development of WinAMP is not dead, it is ongoing -
https://twitter.com/Ed_Rich/status/788650603383754752
But there are apparently administrative or legal issues to overcome in order to release a new version of the player.

[lordmulder]

And no one wants users that endlessly complain about OpenSource software that was kindly contributed to the community for free. Yes, your initial question was legitimate. But now that you have been given the technical explanation, better try reading it again and understand. Please save pointless moaning for someone else. If the software doesn't work for you, then just ignore it. It's not like I asked you to use it! Feel free to come back when you have some suggestion on how the technical limitations can be resolved...

(BTW: Did you consider that most people who use an effect like this will probably use it for movies and the like, where loosing the last couple of seconds is not really a deal-breaker)

[phistuck]

I do not know C++ much, I do not know the WinAMP plugin system at all and I know practically nothing about the technicalities of audio processing, so I cannot help with code, unfortunately (otherwise, perhaps I would have created a similar plugin myself).
I do contribute to open source (and publish some as well) and I think my second comment was actually relevant. To that effect, I submitted a pull request for the readme file, to make it clear that there is a bug in WinAMP -
#13

[lordmulder]

Simply put, the DSP plugin exposes this function, which Winamp is going to call many times:

int modify_samples(struct winampDSPModule *this_mod,
    short int *samples, int numsamples, int bps, int nch, int srate)
{
    /** process samples here **/
}

Here numsamples indicates the number of input samples that Winamp provides to the plugin in the current call, *samples is a pointer to the buffer where the input/output samples are stored, and the function's return value tells Winamp how many output samples the plugin has written back to the buffer this time.

There really is not much to do, except for "pumping" the provided input samples into the "core" Dynamic Audio Normalizer library. This and: Push back the available output samples to Winamp – if any yet.

The only part that is a bit "tricky" is detecting seeks. That's because Winamp doesn't indicate seeks to the plugin at all, to the best of my knowledge. Nor does it re-initialize the plugin on seek. This is why we need to query the current "position" (time) and watch out for timestamp discontinuities – in which case we will trigger a reset() of the "core" Dynamic Audio Normalizer library. Otherwise, if seeks weren't detected, it would take about ~15 seconds after each seek until you actually hear the audio from the new seek position.

Ideally, Winamp should keep track of how many "pending" (outstanding) samples there still are in the DSP plugin. And, at the end of the track, Winamp should "flush" those pending samples out of the plugin – e.g. by feeding enough "dummy" samples into the plugin. If Winamp doesn't do that, what can I do? 😬

[phistuck]

Thank you for the detailed explanation.

I think my pull request makes sense here. For those that want to use the plugin for movies, that comment should not matter much and for those that want to use the plugin for music, they will be warned and have their expectations set.

[lordmulder]

FWIW, I have dropped the "seek detection" workaround from the Winamp plug-in, because it is an ugly hack and was never working reliably. This fixes your "cut off" problem, but of course causes other issues:
DynamicAudioNormalizer-TEST.2017-06-08.Static.zip

Also added a few words to the documentation:
http://muldersoft.com/docs/dyauno_readme.html#known-limitations