[X] Action Schreibweise "_ALL": Normal not always working

Bug Reports No Bugs
#1

hi!

since this never happened to me before, this could be a possible bug.
i have ever since specified an action Schreibweise "_ALL": Normal, that used to work just fine.
however i stumbled upon a mp3 file where this action has no effect on the first character of each tag. i double checked that there is no whitespace character in front...

if i manually edit the first character of e.g. the artist tag and save, the action can then be used normally. maybe an ecoding issue, not sure...

i could provide a link to a sample mp3 file per e-mail for debugging.

greetings,

blubserl

#2

Proposal for giving the forum users insight into the probably bad mp3 tag.

  1. Open the notepad editor and write the word "TEST".
  2. Save this text as a file with the name "TEST.mp3.txt".
  3. Rename the file "TEST.mp3.txt" to "TEST.mp3".
  4. Open Mp3tag and load both files, the "TEST.mp3" and the probably bad mp3 file.
  5. Select the bad mp3 file and copy its entire tag from the bad file by [Ctrl+C] into the Mp3tag clipboard.
  6. Select the test file and paste the Mp3tag clipboard by [Ctrl+V] into the test file "TEST.mp3".
  7. Open the Mp3tag dialog "Extended Tags..." and check the tag content within the test file, it should now have the same content as the probably bad mp3 file.
  8. Attach the test file to your next forum message, maybe as a zip archive.

DD.20160229.1244.CET

#3

thanks for this idea!
here it is...the action doesn't work with this generated test file too...

Test.mp3 (2.16 KB)

#4

just noticed total commanders mp3tagview plugin also has problems with this file (see attachment), so most probably this is some strange encoding or wrongly tagged file...


#5

Test.blubserl.defekt.mp3
Test-Formatstring:
$ord(%TITLE%) - $ord(%ALBUM%) ### %TITLE% - %ALBUM%
==>

65279 - 65279 ### ??burn - ??ready To Die

------------------^--------^-------------

Each tagfield contains a doubled leading Unicode character sequence "FF FE FF FE", ...
which is somewhat suspicious.
In Mp3tag dialog "Tag-Tag" preview it is shown as one symbol "square", ...
but in fact it is a byte sequence, with a special meaning.
In general "FF FE" this is the leading character sequence to define the byte order within the following string of Unicode byte sequence.

0100 49 44 33 03 00 00 00 00 10 17 54 41 4C 42 00 00 ID3.......TALB..

0110 00 1D 00 00 01 FF FE FF FE 72 00 65 00 61 00 64 .........r.e.a.d
0120 00 79 00 20 00 54 00 6F 00 20 00 44 00 69 00 65 .y. .T.o. .D.i.e
0130 00 54 49 54 32 00 00 00 0D 00 00 01 FF FE FF FE .TIT2...........
0140 62 00 75 00 72 00 6E 00 00 00 00 00 00 00 00 00 b.u.r.n.........

Assumable something has happened with the text data, which has created the given situation with the doubled byte order mark.
This situation can be repaired by ...

Convert "Tag - Tag" ... or ... Action "Format value" Field ......: TITLE Formatstring: $regexp(%TITLE%,'^\x{FEFF}',)

DD.20160229.1927.CET

#6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.