Viper DDC & Convoler

[ZN0N15]

I know this project is still a work in progress, but will Viper DDC and the Convoler feature be re-implemented? I have many of my AutoEQ Profiles in DDC and .Wav formats which I mainly used in the OG Viper4Android and also JamesDSP. It would be great to have those features in this RE project of Viper4Android which I'm now currently using. Will there be any plans to get them working?

[iscle]

Hi!

Yes, DDC and Convolver will be RE'd too, but they rely on the most complex class that ViPER has. The processing function is over 2000 lines, and it makes use of the ffts library, which got inlined by the compiler and makes RE'ing it a lot harder (we need to separate the library from the actual ViPER code).

I'll update the issue when it's ready to test.

[ZN0N15]

That's great to hear! Thank you for the confirmation! I'll be looking forward for future updates. For now I'll just deal with using the Fixed FIR EQ. The OG Viper4Android seems to no longer work since Magisk 26 came out, so I've decided to follow this RE Project instead.

[iscle]

Update: DDC is working in my private build, will release an update today or tomorrow 👌🏻

[devnoname120]

@Iscle This is awesome! Any chance you could integrate AutoeEq into it?

Here is an excerpt from jaakkopasanen/AutoEq#315:

To make AutoEQ profiles compatible with Viper4Android/JamesDSP, luckily there's a tool called DDCToolbox that can import *ParametricEQ.txt and convert them to VDC (V4A/JDSP EQ file format).

Porting the conversion logic to Android could enable a seamless integration. There could even be an integrated "store" to download and apply profiles easily.

[iscle]

The update has been published. Right now it's 1:1 with the old viper DDC, meaning it only supports 2 sampling rates and no autoeq integration.

However, I'm planning to do a new file format which allows passing the desired eq values (instead of A1, A2, A3, B1, B2, B3 for each), so that we can dynamically calculate the biquad parameters depending on the sampling rate, and not have to do the reverse equation like JamesDSP does.

By the looks of it, this new file format I'm thinking of is very similar to the AutoEQ file, however, I would like for mine to be in binary format, for ease of parsing in native code, instead of relying on kotlin to do it. (This will come handy when porting viper to other platforms, like STM32, ESP32, linux, windows, mac os, etc).

When the new format is implemented, I can easily do the conversion from AutoEQ to viper in the app, but the driver itself will not have support for it directly (however, if you're using the prebuilt stuff from us, it will be seamless).

[devnoname120]

@Iscle Awesome, thanks for the reply. I can't wait to try it out!

[ZN0N15]

@Iscle I know it's only been three months since this was opened/closed, but can I ask if there is any progress with RE'ing the Convolver feature, if such feature is still being worked on or if its even possible at all? Sorry for asking for an update so early, just wanting to know if the Viper RE project is still alive.

[Scj60963]

I want the convoler function very much ,can it be still in your consideration?

[ThreeDeeJay]

@Iscle I know it may be too early to tell, but any idea if it would be feasible to implement a 14-channel convolver to virtualize surround sound (7.1, 5.1, etc) from apps that can output it? Kinda like HeSuVi on Windows (which even works with only 7 by reusing virtual speakers in the left for the ones on the right by swapping channels), it would be a great replacement for Dolby Atmos virtualization (though not proper 3D spatial audio like Atmos for headphones, of course)

[username227]

I would also very much like headphone surround, which I understand is connected to Convolver. I'd very much be grateful for any updates. Appreciate all your work on this!