CoreConverter.exe sample shifts and truncation

[L5730]

Hi all,
Firstly, I apologise if this is in the wrong section of the forum. I couldn't find one specific to the command line coreconverter.exe.

OK, what I am doing is piping from ffmpeg to coreconverter to make use of ffmpeg's audio filters and coreconverter's VST DSP support.
I have found that my converted files have some issue with regards to their position and are also cut a little short.

Here is the command line:

ffmpeg.exe > input file > decode 32bit fp and apply gain var (dB) > pipe 32bit fp lpcm audio data out to coreconverter.exe > accept input pipe attributes from pre-defined vars > set output file location > apply VST limiter > dither down to 16bit > convert to output file.

FFMPEG.exe -hide_banner -loglevel panic -i %1 -af volume=volume=%GAIN%dB:precision=float -acodec pcm_f32le -f f32le - | "c:\program files (x86)\illustrate\dbpoweramp\coreconverter.exe" -infile="-" -sourcefreq="!SAMPLERATE!" -sourcechannels="!CHANNELS!" -sourcebits="32" -sourceisfloat -silent -priority="high" -outfile="%OUT_FOLDER%\%~n1.wav" -dspeffect1="VST PlugIn=George Yohng's W1 Limiter=X3A000000433A5C50726F6772616D2046696C65732028783836295C56535433325C47656F72676520596F686E672773205731204C696D697465722E646C6C4C0000000C00008174687265736800004A196A3F0C0000816365696C696E67009632713F0C00008172656C65617365002EF5253F14000081616461707452656C65617365000000000000000000000080" -dspeffect2="Bit Depth=-depth={qt}16{qt} -dither={qt}tpdf{qt}"

Everything works, I get output files exactly how I expect them, but with one problem - the sample lengths aren't the same as their input file.

The Problem:
*1: 64 samples of silence are added to the front of the audio data. This is no major concern, I can live with it just fine.
*2: 64 samples are truncated or 'chopped off' of the end of the audio data. This doesn't seem right to me, and I would like my samples back.


I've tested ffmpeg.exe independently and it outputs exactly the same length as went in.

When I tested coreconverter.exe independently I found the following:

*a: 64 samples of silence were added at the front of the audio data
*b: 448 samples of silence were added at the end of the audio data
*c: The audio data was not truncated.


Is there something I am missing, or some kind of trick to preventing truncation?
I'd rather not specify the time in ms of the pipe, because that's a potential source of error when reading lossy formats, and would require a slower scan to determine the value more accurately (ffprobbe.exe).
I am not averse to just bolting on another 64 samples of silence to the end of the audio from ffmpeg.exe, it doesn't seem hard to do and fairly swift.


Thanks for any help.


dBPowerAmp ref: 15.1
dsp release: 11

[Spoon]

Re: CoreConverter.exe sample shifts and truncation

What are your source files?

Is there something ffmpeg is doing that dBpoweramp could not do itself?

[L5730]

Re: CoreConverter.exe sample shifts and truncation

Thanks for the reply.

Source files are a mixture of formats, one/two channels, sample rates and bit depth (where applicable). Generally speaking they will mostly be Lame encoded CBR MP3 44100Hz.
I am currently testing Lame CBR MP3 and PCM WAV a mixture of bit depths 16-32fp, a mixture of mono and stereo, all at 44100Hz.

There is something I thought was possible with CoreConverter.exe, but it isn't as far as I have tested.
I just want to apply a plain gain adjustment ignoring clipping. Accurate to one decimal place, and at 32 bit floating point precision.

I have tried all available DSPs and I had to resort to using ReplayGain tagged intermediate files, and then RepalyGain apply in a previous project.
I do not wish to create intermediate files this time around.

"Volume Normalise" looked to offer a solution but it didn't seem to ignore clipping. I tried shoving +12dB at a file that is peaking at -0.1 dBFS, it just wouldn't apply the gain.
- Actually, I just tried this as I am replying and it did work...hmm..that seems strange.

OK, a few other things have changed slightly... Note to self: check a lot more things before posting

The 64 samples shift at the beginning appear to come from the VST limiter, as per this thread here "No delay compensation/looks like 64 samples will do".
So that's the front of the file taken care of.
Those extra 448 samples are also likely due to the limiter plugin.

So it would appear all is working correctly with coreconverter.exe
I will do a bit more testing, because I am absolutely positive I couldn't get straight gain adjust, but there it is!

I must have messed up the syntax somewhere, and that gave me the false results.
It "DSP: volume normalise" seems to be working just as expected.



Please disregard most of my groaning and moaning...sorry

Is there a way to extend the file data by 64 samples? CoreConverter.exe is correctly clipping the file to proper length from what it read of the files stream, but because the limiter is shoving things backwards, there is now a loss of 64 samples from the end. Truncated through correct time precision, but not accounting for a VST that didn't report it's delay.

[Spoon]

Re: CoreConverter.exe sample shifts and truncation

These 64 samples, it is likely ffmpeg is not mp3 gapless decoding, like dBpoweramp is.

[L5730]

Re: CoreConverter.exe sample shifts and truncation

[i]There's a reply pending moderation to insert above this../[i]

I've implemented "Volume Normalise" DSP and it is seemingly working perfectly. I think I must have missed a space in the syntax, or tried to be 'cleaver' and remove parameters that I didn't think it needed.
I'd like to fix the lack of delay compensation, but I can just apply a 50ms fade out to cover any potential digital clicks from truncating the last 64 samples.

Spoon, I'm going off of my original topic in the title of the thread here...
I note that you made a suggestion for a similar loudness normalising + hard limit task I was working on some time back, see here, would it be possible to send the text output data to a text file or something, as well as regular progress output to console?

I ask this because I would like to generate a report of the file's loudness prior to processing.

EDIT: Don't worry about that, I am working on a target tolerance. If it's %tolerance% LU out from target, I am skipping the file.
There is an analog dynamic processing chain that the file is played through anyway, I just need to get the file's loudness within suitable bounds for the analog gear to function.

Unless CoreConverter can scan a file faster than FFMpeg and produce a LUFS report (only Integrated Loudness needed), I'll stick to tokenising the output of FFMpeg with ebur128 filter, piped through FINDSTR, via a FOR loop.

[L5730]

Re: CoreConverter.exe sample shifts and truncation

It's definitely not ffmpeg (in this case). With using ffmpeg infile > apply fixed volume > outfile, I get exactly what I started with.

More testing has revealed that, yes, if using this particular VST plugin with coreconverter.exe, there is indeed a 64 sample delay, causing the audio data to be padded with 64 samples of silence at the front and truncated by the same amount at the end.

Please change the title to "Coreconverter.exe sample shift with some VSTs."

64 samples at 22050 Hz is only 3.0 ms, it's a non issue really. I'll just fade it out over 10ms to be safe.

For anyone interested in using ffmpeg to add 10 ms of silence to the audio data, before piping to coreconverter, to avoid this truncation of the audio data, here is the syntax:
This example applies gain in ffmpeg. There is no fade, but that can be added
Define <INPUTFILE>, <GAIN>, <SAMPLERATE>, <CHANNELS>, <OUTFILE> and <OUTPUT_PARAMS>. Probably need some changes to VST settings too.

FFMPEG.exe -hide_banner -loglevel panic -i <INPUTFILE> -filter_complex "[0:a]volume=volume=<GAIN>dB:precision=float[a0];aevalsrc=0:s=<SAMPLERATE>:d=0.01[a1];[a0][a1]concat=n=2:v=0:a=1[a]" -map "[a]" -acodec pcm_f32le -f f32le - | "c:\program files (x86)\illustrate\dbpoweramp\coreconverter.exe" -infile="-" -sourcefreq="<SAMPLERATE>" -sourcechannels="<CHANNELS>" -sourcebits="32" -sourceisfloat -silent -priority="high" -outfile="<OUTFILE>" -dspeffect1="VST PlugIn=George Yohng's W1 Limiter=X3A000000433A5C50726F6772616D2046696C65732028783836295C56535433325C47656F72676520596F686E672773205731204C696D697465722E646C6C4C0000000C00008174687265736800004A196A3F0C0000816365696C696E67009632713F0C00008172656C65617365002EF5253F14000081616461707452656C65617365000000000000000000000080" <OUTPUT_PARAMS>

coreconverter will truncate the added 10ms of silence by 64 samples, rather than the audio data. No need to fade out. Output files will just be a smidgen longer than input files.