Bug #1205: MP3 tags are not fully read - Audacious - OLD, PLEASE USE GITHUB DISCUSSIONS/ISSUES - Redmine

Bug #1205

MP3 tags are not fully read

Added by Artem S. Tashkinov over 1 year ago. Updated over 1 year ago.

Status:

Closed

Priority:

Minor

Assignee:

Category:

libaudtag

Target version:

4.3.1

Start date:

March 13, 2023

Due date:

% Done:

100%

Estimated time:

Affects version:

4.3

Description

Compare what Audacious 4.2 retrieves to what ffmpeg shows:

Input #0, mp3, from '01 - Tillmann Uhrmacher - On The Run (Radio Mix).mp3':
  Metadata:
    title           : On the Run (Radio Mix)
    album           : Dream Dance Vol. 24 (CD 2)
    genre           : Other
    track           : 1
    artist          : Tillmann Uhrmacher
  Duration: 00:04:28.23, start: 0.025057, bitrate: 192 kb/s
  Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 192 kb/s
    Metadata:
      encoder         : LAME3.92

No idea what's happening.

This file could be downloaded here (remove spaces): www25 . zippyshare . com/v/1zmNV4C5/file.html

I have hundreds more files like this one.

audacious.png (40 KB) audacious.png		Artem S. Tashkinov, March 13, 2023 10:00
id3v24.diff (1.13 KB) id3v24.diff	Proposed code-change	Jim Turner, March 17, 2023 21:00
OnTheRun_mp3_data.odt (20.5 KB) OnTheRun_mp3_data.odt	Tag data encoded in song file mentioned in bug	Jim Turner, March 17, 2023 21:01

History

#1 Updated by John Lindgren over 1 year ago

So the artist field is not shown, is that the issue?

Is there a non-UTF-8 character encoding in use here? What are your character set detection settings?

#2 Updated by Artem S. Tashkinov over 1 year ago

So the artist field is not shown, is that the issue?

Exactly.

Is there a non-UTF-8 character encoding in use here? What are your character set detection settings?

This looks ASCII to me, you can download the file after all.

My settings:

Auto character encoding detector for: None

Fallback character encoding: CP1251 - setting it to an empty field changes nothing.

#3 Updated by Artem S. Tashkinov over 1 year ago

It's extremely unlikely that the title and artist tags have different encoding settings, yet the title is parsed and shown, and the artist is not.

#4 Updated by Jim Turner over 1 year ago

File OnTheRun_mp3_data.odt OnTheRun_mp3_data.odt added
File id3v24.diff id3v24.diff added

It appears (at least in id3v24 tags) that a file can contain "empty" tags (zero-length values), at least this is the case here. I believe this code-change will fix this. I've also attached an "od -c" dump of the top of this file (Libreoffice ODF) showing the tags (in blue). The 2 empty tags (WOAF & WOAR) are shown in red, and the "missing" artist tag (TPE1) and value are shown in green following the 2 blank ones. Current Audacious code stops on the 1st empty one (thus omitting the artist.

#5 Updated by John Lindgren over 1 year ago

ID3v2.4 says "A frame must be at least 1 byte big, excluding the header." So the tag is corrupt (probably corrupted by some broken tag editing software). The invalid frames in question, by the way, are:

WOAF - Official audio file webpage
WOAR - Official artist/performer webpage
WOAS - Official audio source webpage

It makes no sense to have an "empty URL" in the ID3 tag.

Now, it may be fine to just skip over the invalid frames. I'll look more closely at your patch and apply it if it looks safe. Thanks for looking into this.