Enhancement Request: Preserve MP3 Metadata When Watermarking

[tim-janik]

Hi.
When using audiowmark to watermark an MP3 file, it successfully reads the MP3, adds the watermark but outputs the result as a WAV file, regardless of the file extension used as the output file name.
I.e. the resulting out.mp3 file with an MP3 extension actually contains WAV file data.
That behavior might be according to spec, but is quite surprising.
And, if the output file is a out.wav file, and e.g. lame is used to re-encode the WAV into MP3 data, the resulting MP3 file will lack the metadata from the original MP3, e.g. title, artist, album.

Here is the process I have come up with to preserve the metadata:

1. Extract the metadata from the original MP3 using ffmpeg.
2. Merge the extracted metadata into the re-encoded MP3 after watermarking into a WAV, using ffmpeg again.

The commands are:

ffmpeg -i input.mp3  -f ffmetadata metadata.txt
src/audiowmark add input.mp3 x.wav 0123456789abcdef0011223344556677 
lame x.wav x.mp3
ffmpeg -i x.mp3 -i metadata.txt -map_metadata 1 -codec copy output.mp3

It would be great if audiowmark could detect that the output file is supposed to be an MP3 file and handle the watermarking process in a way so that the output file is an MP3 with the original metadata intact and encoded with a bitrate similar to the input (some heuristics might be needed to guess the input bit rate). This would greatly improve usability and be less error prone than doing it all manually.

Regarding the WAV output even if the file extension is .mp3, I'd suggest to at least warn the user about the possible surprise and maybe require --force or similar, in case the user really wants that (which is highly unlikely).

To summarize:

• Please catch WAV-in-MP3-file as output.
• Ideally, re-encode MP3 output files.
• Preserve metadata from input MP3 files when producing MP3 files.

If that is preferred, I could help with the creation of a wrapper script to achieve the above. (I just suspect that a standalone script couldn't support streaming mode really well...)

Thanks for consideration.

[swesterfeld]

I've been working on a way to preserve tags for mp3 files by simply using ffmpeg to do the mp3 input/output and starting audiowmark as audio filter from the ffmpeg process. This will not only work for mp3 files but also for other formats that ffmpeg can process while preserving the metadata.

The solution has two parts:

• a new audio filter for ffmpegcalled asubprocess which uses a subprocess to filter the audio
• a new audiowmark input/output format called wav-pipe to handle piped wav files properly

The code for ffmpeg is available in branch asubprocess in this repo: https://code.uplex.de/stefan/ffmpeg - I'll submit this upstream and hope to get some review for the code.

The audiowmark code has been merged into master (documentation is available in https://github.com/swesterfeld/audiowmark#wav-pipe-format).

Example:

ffmpeg -i input.mp3 -af "asubprocess=audiowmark add --format wav-pipe - - f0" output.mp3

[tim-janik]

When using audiowmark to watermark an MP3 file, it successfully reads the MP3, adds the watermark but outputs the result as a WAV file, regardless of the file extension used as the output file name.
I.e. the resulting out.mp3 file with an MP3 extension actually contains WAV file data.
That behavior might be according to spec, but is quite surprising.

I have seen reports from other users running into similar issues.

Since Audiowmark reads files via libsndfile, it happily supports WAV, VOC, FLAC, MP3, OGG/Vorbis, Opus and a few more formats as input, which can easily lead to the expectation that the same format is supported as output format (without reading the full documentation, since the README does point out that only WAV and RAW can be written).

Since Audiowmark happily writes a WAV file as output even if the user provided output file name ends in .ogg, .flac, etc, users might not even detect their error early on. This is aggravated by the fact that many players auto-detect sound formats, so those won't complain about mismatching file extensions either.

To improve usability I'd therefore suggest:
a) At the very least, make audiowmark issue a warning on stderr if a file extension other than .WAV is provided as output file.
b) Ideally, employ libsndfile to write the output file in the same format as the input file. Use best effort, e.g. warn if an MP3 encoder isn't present.