1708 WAV tags saved by Mp3tag fail to show [#14360][#14361]

Post a reply


In an effort to prevent automatic submissions, we require that you complete the following challenge.
Smilies
:D :) :( :o :-? 8) :lol: :x :P :oops: :cry: :evil: :roll: :wink:

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: 1708 WAV tags saved by Mp3tag fail to show [#14360][#14361]

Re: 1708 WAV tags saved by Mp3tag fail to show [#14360][#143

by Peke » Thu Aug 31, 2017 9:23 am

You are right MMW was not calculating Pad char. It is fixed in 1846 all your example files work. It is debatable if CHUNK length should include Padded bytes or not I found it somewhat unclear.

Re: 1708 WAV tags saved by Mp3tag fail to show

by chrisjj » Wed Aug 30, 2017 3:02 pm

Thanks for looking into this Peke.
Peke wrote:Chunk defined to be length 41 Bytes but actually it is 42, uses ID3v2.3 tag format
I think that's incorrect. I think the chunk length is 0x41 bytes as specified. I think the last byte is outside the chunk because it is a pad byte.

Image

As per https://en.wikipedia.org/wiki/Resource_ ... ile_Format
4 bytes: an ASCII identifier for this chunk (examples are "fmt " and "data"; note the space in "fmt ").
4 bytes: an unsigned, little-endian 32-bit integer with the length of this chunk (except this field itself and the chunk identifier).
variable-sized field: the chunk data itself, of the size given in the previous field.
a pad byte, if the chunk's length is not even.
When I lengthen the title by one character, the MM fail disappears:

Image

Re: 1708 WAV tags saved by Mp3tag fail to show [#14360][#143

by Peke » Wed Aug 30, 2017 2:32 pm

Fixed MMW 4.1.18.1846+ to read such files even no changes will be made in MP3Tag.

Also ID3v2.3 with UTF16 tags are now correctly read.

Re: 1708 WAV tags saved by Mp3tag fail to show

by Peke » Sun Aug 27, 2017 11:23 am

Added as http://www.ventismedia.com/mantis/view.php?id=14360 and http://www.ventismedia.com/mantis/view.php?id=14361

NOTE: Unless MP3TAG fixes write bug on its end where it adds JUNK Byte even it is somewhat common practice to make even byte then apps not aware of the bug/feature can even further corrupt the file making irreversibly non playable.

Also please Cross point to this Forum topic as it provides more details.

Re: 1708 WAV tags saved by Mp3tag fail to show

by Peke » Sun Aug 27, 2017 11:07 am

Hi,
I've been able to analyze here are results:
  1. "2 Untitled1 saved by GW 6.30 - title OK in Mp3tag, Explorer and MM.wav" -> Contains only Standard "LISTINFO" chunk and thus all Chunks are under RIFF ISO standard file is OK
  2. "3 Untitled1 saved by Mp3tag v2.83 - title OK in Mp3tag and Explorer, missing in MM.wav" -> "ID3 " Chunk defined to be length 41 Bytes but actually it is 42, uses ID3v2.3 tag format
  3. "4 Untitled1 saved by Mp3tag v2.83i - title OK in Mp3tag and Explorer, missing in MM.wav" -> Identical to "3 Untitled1 saved by Mp3tag v2.83 - title OK in Mp3tag and Explorer, missing in MM.wav" so it observes same issue
  4. "5 Untitled1 saved by Mp3tag v2.83i changed config - title OK in Mp3tag, Explorer and MM - now bad in MM!.wav" -> same as above only change it uses UNICODE ID3v2.4 tag format
  5. "6 Untitled1 saved by Mp3tag v2.83i UTF8 - title OK in Mp3tag and Explorer, bad in MM.wav" -> same as above only change it uses UTF8 ID3v2.4 tag format
  6. "7 Untitled1 saved by Mp3tag v2.83i ISO - title OK in Mp3tag, Explorer and MM.wav" -> "ID3 " present but formatted according to RIFF/WAV ISO Format CHUNK and have correct length it shows/import OK eg. it is correctly terminated without extra ZERO Byte on file end unlike previous 4
NOTE: "ID3 " Chunk is not standard chunk by RIFF ISO see http://www.robotplanet.dk/audio/wav_meta_data/ , https://github.com/mpruett/audiofile/issues/3 , http://wavmetadata.blogspot.rs/ (one with most correct info)

Unfortunately there is a BUG in both MP3TAG and in MMW PLUGIN which makes this bit complicated to debug.

For MMW I'll Add bug in order to Support ID3v2.3 "ID3 " Chunk eg. files 3 and 4 and add correction to Ignore junk ZERO Byte on file end and as you already opened issue on MP3tag you can rise bug there. For that Purpose I uploaded manually corrected files 5 and 6 onto http://www.happymonkeying.com/XoXoTemp/ ... _issue.zip so that you can include them in your archive on Dropbox for future use.

Here is a PIC of my manual FIX (NOTE: FILE size in RIFF Header also needs to be corrected as highlighted)
Image

Re: 1708 WAV tags saved by Mp3tag fail to show

by chrisjj » Sat Aug 26, 2017 7:15 am

Thanks Peke. These files

Image

are here: https://www.dropbox.com/s/hnuzlfx2mqcyt ... e.zip?dl=0 .

Re: 1708 WAV tags saved by Mp3tag fail to show

by Peke » Fri Aug 25, 2017 9:18 pm

Hi,
Sorry for late reply was abroad. Can you please send me DL links to all WAV files you used in tests (both good and bad one) so that I can HEX compare and try to track the issue?

Re: 1708 WAV tags saved by Mp3tag fail to show

by chrisjj » Fri Aug 18, 2017 7:11 am

Workaround discovered:

I tried Mp3tag ISO:

Image

Image

Success!

Image

And in foobar2000:

Image

Binary FTR:

Image

1708 WAV tags saved by Mp3tag fail to show [#14360][#14361]

by chrisjj » Thu Aug 17, 2017 7:16 pm

(In my browser, each wide image gets truncated by the forum. To see it fully, open it in a new tab.)

The good news is that Mp3tag now supports WAV.

The bad news is that the tags don't show in MediaMonkey V4.1.3.1708

If I take a file made by GoldWave with WAV tag that shows fine in MediaMonkey V4.1.3.1708 and save it in Mp3tag v2.83i (with default config), the tag fields fail to show in MediaMonkey.

Mp3tag v2.81i - OK
Image

Windows 7 Explorer - OK
Image

MediaMonkey V4.1.3.1708 - faulty
Image

FooBar 2000 - OK
Image

Hex compare
Image

Looks like an MM bug.

Any suggestions for a workaround on this version of MM?

I tried working around by changing the config inc. Mp3tag Options Tag Mpeg despite that Help says this should not affect WAV, and I got a result that didn't show the problem and had a different encoding:

Image

but I was unable to reproduce this workaround.

(Reported at https://forums.mp3tag.de/index.php?showtopic=22803 )

Top