You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Extract the metadata from the original MP3 using ffmpeg.
Merge the extracted metadata into the re-encoded MP3 after watermarking into a WAV, using ffmpeg again.
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.
The text was updated successfully, but these errors were encountered:
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.
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:
ffmpeg
.ffmpeg
again.The commands are:
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:
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.
The text was updated successfully, but these errors were encountered: