Request for SoxFilter 64 bits

[tebasuna51]

Please, someone can make the 64 bits version of this plugin?

32 bits and sources here https://forum.doom9.org/showthread.php?p=761154#post761154

The author sh0dan is retired in 2016.

[MeteorRain]

I managed to get some binary, but it crashes the moment I load AVS. Need some debug time I guess.

[MeteorRain]

https://down.7086.in/soxfilter_64_r0.zip Try this.

[tebasuna51]

Tanks! Seems work fine.

SoxFilter have many options and I can test all. Also sh0dan say than there are some issues and we never know.

I test a simple filter than crash Avs+ 32 r2772 (https://forum.doom9.org/showthread.php?p=1887661#post1887661) and work fine, also work the 32 bits, I'm using Avs+ r3106 (32 and 64)

Also work a compand function than I need to replace the Audiolimiter plugin (without sources) to make downmix 7.1 -> 5.1 in MeGUI 64.

BTW seems than the 32 bits version is fast, but no problem for me. Thanks.

[MeteorRain]

If you wonder why 32bit is fast, it's because it uses inline asm that I have removed when test compiling 64bit. Please add ConvertAudioTo32bit() before calling soxfilter and see if speed improves.

[MeteorRain]

Nevermind. AVS+ doesn't have 64bit SIMD as well, so it'll be as fast (slow) as the internal conversion.

Maybe someone would one day improve that piece of code.

[tebasuna51]

You are right, now is fast than 32 bits version even when the conversion to 32 int and return to 32 float.

[real.finder]

does the r0 has update the Sox library https://forum.doom9.org/showthread.php?p=1733929#post1733929 ?

[MeteorRain]

Not yet. To make sure it compiles, I used the very same binary to eliminate potential problems. I might clean it up and recompile a r1.

[tebasuna51]

@MeteorRain
About this plugin and your improvements in audio formats conversion (https://forum.doom9.org/showthread.php?p=1916518#post1916518), maybe you want read the VapourSynth Audio thread and how AviSynth must work with audio (https://forum.doom9.org/showthread.php?p=1917206#post1917206) data.

Lossy functions (Amplify..., Resamples..., Filters...) must work always in float format, and the conversion must be automatic, it doesn't make sense work in 16 bit int with the risk of overflow and clip and 0 advantages.

Comments like was make in old Avs+ thread (https://forum.doom9.org/showthread.php?p=1811759#post1811759)and behaviour like:
TimeStretch()

Source clip. Audio is always converted to Float.
AVS+ no conversion is performed. Accepts Float audio only.
and
SSRC()

Source clip. Audio is always converted to Float.
AVS+ no conversion is performed. Accepts Float audio only.
show how Avs+ developers don't understand audio management.

[MeteorRain]

Any reason why the conversion must be automatic?
I always believe the user should have the ultimate power to do whatever they want instead of being told what to do, and should always be aware of what's being done.
If user sincerely wants to run lossy functions on 16 bit, I would rather do it then converting it to float without telling the user.

But anyway that's just my personal opinion.

For now I think a bigger concern is that no one is working on improving the audio part. Current code base still have lots of MMX code that I'd love to delete asap. And I'd hope someone would take time to rewrite it to proper intrinsics. (I've done a bit but I don't have time yet to verify the result and debug that.)

[tebasuna51]

The lossy operations involve audio data and float coeficients, if we operate between integers and float values we obtain float values.
If you do a automatic restore to the int audio format can obtain overflow and clip. Here you do a automatic, and dangerous now, conversion.
Convert to float is 100% safe, operate between floats is safe.

If the user want a final int output must Normalize (or check maxvalue, I don't know how in AviSynth) to avoid clip converting float values > 1.0 to int.

Sorry, I can't help you converting MMX to proper intrinsics.

[MeteorRain]

I see, that would make sense. Yea in AVS we have normalization filter to avoid clipping.

[Wilbert]

Lossy functions (Amplify..., Resamples..., Filters...) must work always in float format, and the conversion must be automatic, it doesn't make sense work in 16 bit int with the risk of overflow and clip and 0 advantages.
If there is overflow or clip in the resulting audio file, it implies that the audio filter contains a bug. That's no different than with video. I would be surprised if there is an automatic 'restore' to int in one of these audio filters you listed.

[tebasuna51]

If there is overflow or clip in the resulting audio file, it implies that the audio filter contains a bug.

Nope, the filter obey the user.

If you put Amplify(2.0) over a int you can obtain overflow (clip) for all volumes over 50%, over float values you can obtain values until 2.0 and after can be Normalized without lose info.

[MeteorRain]

Do you know if there's any updated version of this available somewhere? I noticed huge structure change in later version of sox, and I'm getting lost on what / how to properly process audio data.

[tebasuna51]

Does not exist other version.

I will see the later sox version, but I doubt I can help you.

[MeteorRain]

I'd give up if I can't figure out how to rewrite the code against the later version. It'll then stay with sox 12.17.

[Wilbert]

Nope, the filter obey the user.

If you put Amplify(2.0) over a int you can obtain overflow (clip) for all volumes over 50%, over float values you can obtain values until 2.0 and after can be Normalized without lose info.
Ok good point. I agree with this.

[tebasuna51]

I noticed huge structure change in later version of sox, and I'm getting lost on what / how to properly process audio data.
I'd give up if I can't figure out how to rewrite the code against the later version. It'll then stay with sox 12.17.

No problem for me, of course there are improvements in last version 14.4.2 but nothing important for AviSynth plugin.

Still work internally with int32 samples with the same clip problem than in 12.17.9, for instance:
//Native SoX audio sample type (alias for sox_int32_t).
typedef sox_int32_t sox_sample_t;

//Max value for sox_sample_t = 0x7FFFFFFF.
#define SOX_SAMPLE_MAX (sox_sample_t)SOX_INT_MAX(32)

//Min value for sox_sample_t = 0x80000000.
#define SOX_SAMPLE_MIN (sox_sample_t)SOX_INT_MIN(32)

#define SOX_SAMPLE_CLIP_COUNT(samp, clips) \
do { \
if (samp > SOX_SAMPLE_MAX) \
{ samp = SOX_SAMPLE_MAX; clips++; } \
else if (samp < SOX_SAMPLE_MIN) \
{ samp = SOX_SAMPLE_MIN; clips++; } \
} while (0)
...
sample = gain * *ibuf++;
SOX_SAMPLE_CLIP_COUNT(sample, effp->clips);
*obuf++ = sample;

The samples are clipped without the posibility of recover the float value.

I checked some filters and I obtain bit-identical values with Soxfilter.dll (32 or 64 based in sox 12.17.9) and with sox.exe v14.4.2

We can supply the 32int audio format and soxfilter don't need use the old ASM in Convertaudio.cpp.

I see also some limits in soxfilter:
sprintf(err, "SoxFilter: (%s) Cannot run filters that change the number of channels.", arg_str);

sprintf(err, "SoxFilter: (%s) Cannot run filters that changes the samplerate.", arg_str);

Seems only modify values but not create a new audio with different properties.

There are also:
AVSValue __cdecl Create_SoxFilter(AVSValue args, void* user_data, IScriptEnvironment* env)
{
PClip clip = new SoxFilter(args[0].AsClip(), args, env);
AVSValue Ia[1] = { clip };
return env->Invoke("EnsureVBRMp3Sync", AVSValue(Ia, 1));
}

Seems call a internal Avisynth function, I supose this can't work with VapourShynt.

To finish, for me is enough like is now, don't waste time if don't like it.

[real.finder]

I'd give up if I can't figure out how to rewrite the code against the later version. It'll then stay with sox 12.17.

No problem for me, of course there are improvements in last version 14.4.2 but nothing important for AviSynth plugin.


but there are this bug in the old sox https://forum.doom9.org/showthread.php?p=1733754#post1733754

off topic but, MeteorRain, since you work on audio things, maybe you can add audio support to MP_Pipeline