[FFmpeg-trac] #3125(avformat:new): \\ 'separator' in id3tag causes unwanted truncation of ffprobe output

FFmpeg trac at avcodec.org
Tue Nov 12 16:25:17 CET 2013

#3125: \\ 'separator' in id3tag causes unwanted truncation of ffprobe output
             Reporter:  ginjaninja  |                    Owner:
                 Type:  defect      |                   Status:  new
             Priority:  normal      |                Component:  avformat
              Version:  git-master  |               Resolution:
             Keywords:  id3         |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |

Comment (by ginjaninja):

 From another post i now realise that !\\ is treated as special by mp3tag
 (the client i use to write tags). I had thought it was just a.n.other text
 string, but it turns out that !\\ actually instructs mp3tag to write
 something special to the header.

 for flacs the header (when viewed in hex editor) has
 so ffmpeg isn't truncating a text string past the last !\\, it is perhaps
 just not multi-value aware.

 for mp3 the header is TPE1 artist1[00][00][00]artist2[00][00][00]artist3
 and ffmpeg\ffprobe reports artist as artist1 (ie doesnt read past the 1st
 null character?)

 so perhaps there is no standard for ffmpeg to accommodate? perhaps it is a
 peculiarity of the mp3tag client and the way it writes headers. Still it
 would be great if ffmpeg did support such headers by using its own format
 for output of multi value tags.

 I understand other clients do write headers in a similar way. If the user
 could specify the text character to use to delimit the output for eg a
 multivalue artist field (such as the way they are written here by mp3tag),
 then my client would be able to see multiple artists as they were intended
 (it uses ffmpeg (ffprobe) to extract tags from files). My client could
 parse the output of ffmpeg (ffprobe) with the known separator to derive
 the multiple artists.

 more universally, when using ffmpeg to transcode content, maybe if ffmpeg
 had an appreciation of these types of multi value headers, it could ensure
 they are written to the destination in the same format?

Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/3125#comment:7>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list