1

I'm using ffmpeg to change bitrate of my mp3 files. It works well, but one thing is very frustrating.

ffmpeg automatically changes some of metadata fields. Specifically it converts ID3v2.3 to ID3v2.4, and it does it incorrectly. For example, it writes TYER field that actually does not exist in ID3v2.4. But the most frustrating thing is, it converts USLT field to lyrics-LANGCODE(like lyrics-eng). Most of music players does not recognise this tag!

I don't want ffmpeg to mess up with metadata fields. I just want it to change bitrate. Is there anyway to tell ffmpeg that it should not touch any metadata fields?

I'm running ffmpeg 4.0.2 in windows 64bit. Options are:

ffmpeg -i input.mp3 -codec:a libmp3lame -b:a 128k output.mp3

And no, -id3v2_version 3 did not help. It corrected TYER problem, but not lyrics problem.

he rambled
  • 154
  • 2
  • 8
  • 1
    FFmpeg will rewrite tags and default ver is 2.4. Lyrics will also be written as you've seen. Can you reconfirm with the output file that TYER was written with your first command? – Gyan Jul 31 '18 at 16:55
  • @Gyan Yes, it writes TYER if original file is 2.3. Not if original file is 2.4, though. – he rambled Jul 31 '18 at 17:05
  • 1
    Can't reproduce it here. Checked with Exiftool. You are checking the output in a separate command after creation? – Gyan Jul 31 '18 at 17:14
  • @Gyan I checked with hex editor. Did your input file have `TYER` field? My (id3v2.3) input file had `TYER` field, and I suspect that ffmpeg is just copying this `TYER` field instead of replacing with correct one. – he rambled Jul 31 '18 at 17:20
  • 1
    I rechecked using `strings`. It's there in my input; it's there with `-id3v2_version 3` output; not there without. – Gyan Jul 31 '18 at 17:35
  • @Gyan That's strange. I still see `TYER` in output without `-id3v2_version 3`. Here's the [file](https://drive.google.com/file/d/1BLXZ9YhAhlO5SxrpD0MDgMpWXJ7-TxWR/view?usp=sharing) I used to reproduce this behavior. Command was simple: `ffmpeg -i test1.mp3 test2.mp3` – he rambled Jul 31 '18 at 18:04
  • 1
    Th input tag is malformed. TYER is supposed to be [exactly](http://id3.org/id3v2.3.0#Text_information_frames) 4(+1) chars; in your input it is 10 chars. ffmpeg's ID3 parser doesn't abort cleanly and writes the key+value in a TXXX frame into the output. May be considered a bug. – Gyan Jul 31 '18 at 19:22
  • @Gyan I see. My original input file stores whole month and day into a field that should contain only year, and that is the problem. I should look for a better store XD. However the real problem about lyrics remains... I might just switch to other converter. – he rambled Jul 31 '18 at 19:27
  • @Gyan Thank for the effort and very kind response anyway! – he rambled Jul 31 '18 at 19:38
  • 1
    https://stackoverflow.com/questions/26109837/convert-flac-to-mp3-with-ffmpeg-keeping-all-metadata may be useful – rogerdpack Aug 03 '18 at 20:15

3 Answers3

0

I couldn't solve the lyrics problem with ffmpeg but was able to copy lyrics from the LYRICS-ENG metadata field to the USLT field.
I used the Mp3tag tool for batch copying of the data.
It has the Actions feature for batch operations.

What I did:

  • Actions -> Actions
  • New -> New -> Format value
  • "Field": UNSYNCEDLYRICS, "Format string": %LYRICS-ENG%
  • Navigate to a folder with the files, select them and execute the created action
mortalis
  • 2,060
  • 24
  • 34
0

I used a mix between ffmpeg and the first answer to this question: I first convert a full folder of files thanks to the cmd loop below (in this case converting .flac files to .mp3). Right now I am changing the bitrate of my entire iTunes library so that it takes less place, and ffmpeg does indeed change the tag of the lyrics. But using mp3tag and creating this action allows me to switch them back to a tag that iTunes knows. This is a very quick way of doing it, and I was searching for it for a very long time !

FOR /F "tokens=*" %G IN ('dir /b *.flac') DO ffmpeg -i "%G" -ab 320k -acodec mp3 "3%~nG.mp3"
0

i have found several approaches that do something that may work but i do not think that it is currently possible to completely fix that issue.

[every time you see an "{lyrics}" in this answer you have to replace it with the actual lyrics, you can get those using external tools like ffprobe in combination with grep or, for example, the npm package music-metadata]

with the command

$ ffmpeg -i input.mp3 -metadata "lyrics-eng" -metadata "unsyncedlyrics=eng||{lyrics}"

you can clear the TXXX:lyrics-eng field and instead write them to TXXX:unsynchedlyrics. Mp3Tag recognizes the latter the same as normal USLT and if you save the file using Mp3Tag (without changing anything) it automatically reverts back to USLT

with the command

$ ffmpeg -i input.mp3 -metadata "lyrics-eng=" -metadata "lyrics=eng||{lyrics}"

ffmpeg adds your lyrics as "TXXX:USLT". Mp3Tag does not recognize those at all.

the hacky workaround that i ended up using (on windows), was to copy them using the first method, open them all in Mp3Tag using its command line interface ($ Mp3Tag.exe /fn:"<file name 1>" /fn:"<file name 2>" ... /fn:"<file name n>") and then just press ctrl+a and then ctrl+s

may
  • 27
  • 5
  • Are you sure @m4rch? In my case this results in a mp3 with a id3v2.3 tag UNSYNCEDLYRICS with the content `eng||{lyrics}` literally - the {lyrics} part will not be replaced with the original text from my original *.flac input file. This is also true if I use `eng||{USLT}`. Any other ideas how to copy existing lyrics? – PeterCo Mar 24 '22 at 11:11
  • 1
    no i am sorry, i formulated my answer poorly, you first have to extract the lyrics from the file (you can use ffprobe) and then add insert them there. i will rephrase my answer. also it does not actually do what i had thought it would do back then because it worked in my case but it actually does not add a USLT tag back, but instead a TXXX:unsychedlyrics tag which may work, as it did for me back then, but it still is something different. – may Apr 20 '22 at 19:09