unexpected `error: input frames (357913941) != output frames` on reading from stdin about audiowmark HOT 6 CLOSED

oh, seems like I didn't test it well.
just noticed any piped input generates the error

user@laptop:~/ $ cat ~/work/audiowatermark/original.wav | ~/src/audiowmark/src/audiowmark add - - 0123456789abcdef0011223344556677 > /dev/null
Input:        -
Output:       -
Message:      0123456789abcdef0011223344556677
Strength:     10

Time:         124:16
Sample Rate:  48000
Channels:     6
audiowmark: error: input frames (357913941) != output frames (6045696)

user@laptop:~/ $ file ~/work/audiowatermark/original.wav
~/work/audiowatermark/original.wav: RIFF (little-endian) data, WAVE audio, 6 channels 48000 Hz

user@laptop:~/ $ ~/src/audiowmark/src/audiowmark add ~/work/audiowatermark/original.wav - 0123456789abcdef0011223344556677 > /dev/null
Input:        ~//work/audiowatermark/original.wav
Output:       -
Message:      0123456789abcdef0011223344556677
Strength:     10

Time:         2:05
Sample Rate:  48000
Channels:     6
Data Blocks:  2

from audiowmark.

Seems like the problem is in this line of libsndfile

psf->sf.frames = psf->datalength / psf->blockwidth ;

maybe its parameters are wrong or the computation itself. But when the file comes as an audiowmark param libsndfile goes another branch and psf->sf.frames is computed a different way.

from audiowmark.

got it. the problem is not in libsndfile but in ffmpeg with which I got my original.wav via pipe.
apparently ffmpeg can't properly detect number of frames from an encoded audio track and writes some large number to the wav header and of course it can't fix it in the end of the processing because of pipes nature.
I guess it's somewhat unfixable and I need workarounds.

from audiowmark.

apparently ffmpeg can't properly detect number of frames from an encoded audio track and writes some large number to the wav header and of course it can't fix it in the end of the processing because of pipes nature.

Yes, this is probably what is happening here. There are other cases that trigger this, for instance if you want to use madplay to decode mp3s and then watermark the result, like described here:

https://groups.google.com/g/audiowmark/c/1PPrvwOHhSo

The thing is, even if we don't know the number of input samples, we can watermark the audio file just fine. The error message is generated after the watermarking is complete, so you can use the audio that is produced by audiowmark even if the error occurs. Of course we then also won't know the number of output samples when writing our output wav header. But in some cases (like if you want to re-encode as mp3) this doesn't matter at all.

So I think while it makes sense to have this check, I think in the future we somehow should support these cases without generating an error. One possible solution would be to make this a warning, and possibly add an extra option to treat warnings as errors (this is what flac does).

from audiowmark.

I agree about warning.
But I'm a little worried about libsndfile if it has any special logic which may operate on invalid number of frames.
So I guess we need to some option for libsndfile too, like "force unknown number of frames, ignore number in the header".

In any case it's nice to have some FAQ/Known Issues doc with this problem.

from audiowmark.

I agree about warning.

I made it a warning now, you can use --strict to get back the old behaviour.

But I'm a little worried about libsndfile if it has any special logic which may operate on invalid number of frames.

I'm not too worried here, as far as I know libsndfile can deal with these files just fine, these are valid wave files which just happen to have a large number of frames. But the libsndfile sample number counter sf_count_t is a 64bit integer, whereas the number of frames in a traditional wave file is a 32bit integer for the number of bytes, so there shouldn't be any problem with arithmetic operations on the wave file size.

from audiowmark.