BUG: alt+3 on a mp3 causes crash

[MrSinatra]

ok, so I'm not sure if I have the 3516 dll, the 3512 one, or the beta 105 that was pulled, but I suspect I have the 105.

anyway, when I alt+3 this file, winamp immediately crashes. can anyone reproduce?

it seemed to check out as ok in mp3val and mp3tag, all I see "odd" is an embedded art, but other embeds don't seem to cause an issue. I can read/refresh the metadata and play the file.

[MrSinatra]

well, I can't upload the 9meg mp3 as a zip b/c winamp servers still can't handle uploads properly:

"Your submission could not be processed because a security token was missing.

If this occurred unexpectedly, please inform the administrator and describe the action you performed before you received this error."

[MrSinatra]

https://www.dropbox.com/s/81wb9uytaf7fjjr/Isaac%20Hayes%20-%20Hung%20Up%20On%20My%20Baby.mp3

[DrO]

knowing what version of in_mp3.dll you're using is imperative (especially as 105 is not supported).

[MrSinatra]

it appears to be the 105 ver, if I can trust the file properties. but the mp3 file might provoke the bug in the other versions as well.

I assume the feedback is useful even if not supported, since presumably the next released dll will have evolved from 105?

[DJ Egg]

No, the next version will have evolved from v4.103, which is the recommended and only supported version of in_mp3

http://forums.winamp.com/showthread.php?t=373755#updates

in_mp3 v.4.104, included with the 5.6.6.3516 distro is bugged, and 105 was accidentally leaked and should never have been made available.

I can't reproduce any crash with that mp3 file when using 5.666 build 3516 and in_mp3 v4.103

p.s. I'll take a look at the attachment issue...

[thinktink]

I can't reproduce it with a 3516 install (without regressing in_mp3.dll to ver 3512) with the linked file. There's also no artwork in that linked file. I also tried with in_mp3.dll v 3512, no issues.

[DrO]

i've replicated a crash using the internal code for the plug-in which has moved on from where it was with the last build (which is based on 103/104 but with different fixes for the issues which 105 attempted to resolve after the 104 debacle).

the issue is down to the embedded artwork which is not reporting a correct mime type and we're then crashing due to not handling that correctly (i need to dig deeper into what is actually wrong - since mp3tag doesn't like it at all but i can see the artwork correctly). it's only going to happen on the alt+3 dialog due to it trying to provide more information about the artwork on the page.

the fix for the crash is simple and already done at the time of this reply, but like i've said above, i'll need to dig deeper into what's in the tag itself to see what we should be reporting for it or not (as the attached image shows what i'm seeing on the UI after making the crash fix).

[MrSinatra]

ok, this just got really bizarre... that's NOT the artwork that I see. and obviously "fresh cream" is not the right artwork either for an Isaac Hayes song.

DrO, are you sure that artwork is not as a result of a cream cover file in that folder? I know it says embedded...

but anyway, this is going to take some explaining, and I don't have proof just observations, so bear with me:

that mp3 was DL'd from the internet. turns out that in my dir/folder, I had the correct artwork placed there by WMP, the typical 4 system/hidden files. I've attached the Folder.jpg

when that is in the folder with the mp3 and I do alt+3, winamp crashes. if I take it out of the folder and do alt+3, no crash!

however, I see no artwork in alt+3 at all when it opens.

so I am curious how you got the crash to reproduce if no artwork was in the folder?

I also don't see any artwork in mp3tag, but it does report something as being in there, possibly a png, which it says is 0x0 and 161KB. so, mp3tag reports that it has an embedded cover, BUT it does NOT show me any kind of cover, and that's with or without the folder.jpg in the folder.

in the winamp display pane funnily enough, if the folder.jpg is in there and I do a manual refresh, it works, and if it isn't in there, llama.

(and something I discovered from this, is that the two other i.hayes mp3s I have in that folder, were displaying a different, older, pre-WMP placed folder.jpg artwork. so winamp was displaying, for those two, a cached version and not replacing it with the newer artwork, even after rescans; and yet it WAS displaying the WMP one for the one mp3 I linked above, so it seems as if the bug also somehow provoked an automatic artwork display refresh??? ...unless I manually did that one some time ago and don't recall doing so)

[MrSinatra]

ok, I forgot to add an important point to the above...

when the Folder.jpg was in the folder with the mp3 linked above, windows explorer would show the file icon the way it does when a mp3 has an embed, the art becomes the icon. (the other two just had normal icons, no sign of embeds)

that's why I thought that pic was also embedded in the file. but now, after I've taken the Folder.jpg out of the folder, and then put it back, it no longer does that. it just has the winamp lighting bolt icon look my other non-embed-files would normally have.

so its just another damn baffling observation, this time more about windows explorer than anything else.

[Aminifu]

"Mp3 Diags" reports that the file has an embedded image tag, but that there is an unspecified error when trying to load the image.

I don't think Winamp should be accused of bugs when the file itself has errors. It is difficult at times to verify the integrity of files, which is why I use 2 or 3 error checkers (different apps detect different things) to examine them during my vetting process for files I don't make myself.

Winamp is more sensitive to file format structural errors than many other media players, but I think that is a good thing.

[MrSinatra]

wrong. if winamp * crashes * b/c of some strange art embed, that is a bug in error handling.

to be fair however, I am using 105 which is not official. not sure if DrO got a crash with released vers or only other betas/105.

[Aminifu]

My opinion is not wrong. It's just an opinion that you disagree with.

[MrSinatra]

wrong. you are entitled to your own opinion, not your own facts. it is a FACT that there is a bug in the error handling of this file by winamp, when using 105. that is not an opinion, it is a fact, ergo it is entirely appropriate to "accuse" (aka demonstrate) winamp of having a bug.

again, as I said, to be fair I did not experience the bug in released vers, altho as I noted, I did not test it with released versions.

[Aminifu]

it is a FACT that there is a bug in the error handling of this file by winamp, when using 105.

How do you know if this particular error is even detected? It must be detected before it can be handled. There is a practical limit on what errors can (and should) be detected.

I think users should bear some responsibility for the integrity of the files they use.