BUG: bad embed art crashes when folder art present

[MrSinatra]

ok, so here's a weird one. might be known, already reported, as it seems vaguely familiar.

i have a file that mp3tag reports as having an embedded artwork, but neither winamp nor mp3tag shows it. i assume its "bad" somehow.

its in a folder with an ext Folder.jpg file. when i try to do "View File Info" with winamp, it crashes immediately. an "edit" does not crash it.

if i move the art file out of the folder, i CAN do View File Info, no crash. (but nothing makes the embed visible, in either app, ergo "bad embed")

also want to mention i am using v105 inmp3, but i would guess this bug is in unpatched and normally patched inmp3 vers as well.

link to file:

https://www.dropbox.com/s/lyxyhui7ou...4%20U.mp3?dl=0

[DJ Egg]

MP3 Diags reports that the ID3v2 tag has an APIC frame, but the image couldn't be loaded.
"Error loading image in APIC frame. The frame is too short anyway to have space for an image."
"APIC size = 13. Status = error."

So yes, it's corrupt, and you should delete it (the relevant image tag)

As for the crash, you shouldn't be using in_mp3 v1.05
Only v1.03 is officially supported, and my guess would be that there's no crash when using it.

______________________

[ryerman]

Originally Posted by DJ Egg

As for the crash, you shouldn't be using in_mp3 v1.05
Only v1.03 is officially supported, and my guess would be that there's no crash when using it.

I tried it with in_mp3 v1.03 and there was no crash.
Plus, the folder.jpg was displayed as album art.

[MrSinatra]

Originally Posted by DJ Egg

MP3 Diags reports that the ID3v2 tag has an APIC frame, but the image couldn't be loaded.
"Error loading image in APIC frame. The frame is too short anyway to have space for an image."
"APIC size = 13. Status = error."

So yes, it's corrupt, and you should delete it (the relevant image tag)

As for the crash, you shouldn't be using in_mp3 v1.05
Only v1.03 is officially supported, and my guess would be that there's no crash when using it.

Egg, you posted 105, and it works fine for me, save this one instance. its kind of nonsense to say i shouldn't be using something you posted, is it not? i DL'd, installed, and used it prior to any official withdrawal and i don't believe there is any onus on me whatsoever to stop using it, is there?

i agree it isn't officially supported, ergo why i mentioned it. it might however illuminate as to an issue in yet to arrive future inmp3s, which is another reason why i mentioned it.

now, it may already be fixed in the alpha you are playing with, and that may be b/c of a previous report, b/c as i mentioned, this seems vaguely familiar, ie. the crash with the folder art in the folder as opposed to not in the folder. i'm glad to hear it doesn't crash 103, (which might also be due to a previous bug report), but my only intention is to help you devs going forward.

if it doesn't help, fine, but i don't think its appropriate to tell me what i should or shouldn't do with something you posted.

Originally Posted by ryerman

I tried it with in_mp3 v1.03 and there was no crash.
Plus, the folder.jpg was displayed as album art.

ryerman, had you first scanned it into the ML? or just played it via doubleclick in windows explorer?

[ryerman]

Originally Posted by MrSinatra

ryerman, had you first scanned it into the ML? or just played it via doubleclick in windows explorer?

It was scanned in like every other audio file in the Library.
All my audio files are associated with MediaInfo, so it was impossible to double click and play in Winamp.
I then removed it from the Library and used the "Open with" menu in Windows Explorer: the art was displayed and there was no crash when using "View file info...".

[MrSinatra]

Originally Posted by ryerman

It was scanned in like every other audio file in the Library.

ok. i was just asking b/c its possible to play/view file info a given file without it being in the ML.

Originally Posted by ryerman

All my audio files are associated with MediaInfo, so it was impossible to double click and play in Winamp.

ok, np. just curious.

Originally Posted by ryerman

I then removed it from the Library and used the "Open with" menu in Windows Explorer: the art was displayed and there was no crash when using "View file info...".

ok, i just wanted to verify your testing was done with it already in the ML. its quite interesting that this bug is in the 105, but not the 103. it begs the question if its in the 104 and in whatever alphas / betas exist deep in the underground bunkers of radionomy.

[ryerman]

Originally Posted by MrSinatra

whatever alphas / betas exist deep in the underground bunkers of radionomy.

Judging by the amount of communication from those bunkers, whatever is in there must be top-secret, hush-hush and of utmost importance to the security of Radionomy, and/or Belgium and probably the world.

[Aminifu]

MrSinatra, you are a stubborn 'son of a gun'. The counter arguments to your pov in post #4 above are obvious. However your approach has 'born fruit' on occasion, so I don't have to say keep it up, I know you will.

[MrSinatra]

Originally Posted by Aminifu

The counter arguments to your pov in post #4 above are obvious.

no, they aren't.

anyway, the other thread relating to this bug:

http://forums.winamp.com/showthread.php?t=377054

[Aminifu]

Would you keep using a recalled smartphone because your's hasn't caught fire yet? Would you keep using a recalled airbag because your's hasn't exploded yet? Would you keep eating a recalled food product because your's hasn't made you sick yet? I'm sure you can add other recall examples.

Once a vendor has announced the recall of a product, the onus IS on you to handle it in the manner that the vendor recommends. Once a faulty product is discovered, a responsible vendor SHOULD tell you what you should and shouldn't do with it.

This is only a recalled software module and it can't physically hurt you, but the obvious point is the same. If you experience bad results from using it (after you have been TOLD not to) then the fault (and responsibility) is yours, not the vendor's.

I'm confident that the Winamp developers investigated the faulty module BEFORE issuing the recall and will try to keep the underlying problem(s) from reoccurring.