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.

Thanks for looking into this Peke.

[quote="Peke"]Chunk defined to be length 41 Bytes but actually it is 42, uses ID3v2.3 tag format[/quote]
I think that's incorrect. I think the chunk length [i]is[/i] 0x41 bytes as specified. I think the last byte is outside the chunk because it is a pad byte.

[img]http://i.imgur.com/XCMdkZk.png[/img]

As per https://en.wikipedia.org/wiki/Resource_Interchange_File_Format
[quote]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.
[b]a pad byte, if the chunk's length is not even.[/b]
[/quote]

When I lengthen the title by one character, the MM fail disappears:

[img]http://i.imgur.com/mWdRqro.png[/img]

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.

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.

Hi,
I've been able to analyze here are results:
[list=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
[*]"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
[*]"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
[*]"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
[*]"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
[*]"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[/list]

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/Corrected_Tracks_for_MM_WAV_tag_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)
[img]http://www.happymonkeying.com/XoXoTemp/Corrected_Tracks_for_MM_WAV_tag_issue.jpg[/img]

Thanks Peke. These files

[img]http://i.imgur.com/Eu7Btek.png[/img]

are here: https://www.dropbox.com/s/hnuzlfx2mqcyth3/Tracks%20for%20MM%20WAV%20tag%20issue.zip?dl=0 .

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?

Workaround discovered:

[b]I tried Mp3tag ISO:

[img]http://i.imgur.com/jIJ2bSD.png[/img]

[img]http://i.imgur.com/ACIbH02.png[/img]

Success!

[img]http://i.imgur.com/H4FNyXk.png[/img]

And in foobar2000:

[img]http://i.imgur.com/eZRuudK.png[/img]

Binary FTR:

[img]http://i.imgur.com/IJXZjuP.png[/img][/b]

(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
[img]http://i.imgur.com/Rwpt0zy.png[/img]

Windows 7 Explorer - OK
[img]http://i.imgur.com/RxlUFGP.png[/img]

MediaMonkey V4.1.3.1708 - faulty
[img]http://i.imgur.com/X82zDkN.png[/img]

FooBar 2000 - OK
[img]http://i.imgur.com/Vgrcgmc.png[/img]

Hex compare
[img]http://i.imgur.com/WvVgbCB.png[/img]

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:

[img]http://i.imgur.com/syD4PLr.png[/img]

but I was unable to reproduce this workaround.

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