Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: winamp couldn't read metadata (Read 13183 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

winamp couldn't read metadata

Hi, I'm kinda noob so bare with me.

I just download new WavPack winamp plugin version 2.4.  I notice some portion of my wavpack file doesn't display correctly in winamp(I use winamp 5.32).  No tag is read and it just display filename on the playlist.  Later I found out that these files have been tag using other program(not foobar) like tag&rename or some other prog I can't remember.  Can you tell me how to display these file correctly and how to write the tag to the correct format.  I also want to know what's different between plugin version 2.3 and 2.4.  I did read your changelog

Quote
in_wv.dll (winamp plugin) - 2.4
-------------------------------
  fixed: quietly skips deleted files in playlist
  improved: more robust handling of corrupt files


But I don't know what this have to do with reading metadata in tag files.  :\

winamp couldn't read metadata

Reply #1 –
maybe nothing?

if you use foobar2000, check to see if the tags are there. as for tags, WavPack uses APEv2 and ID3v1(not even sure why). foobar2000 reads and writes APEv2 by default.

winamp couldn't read metadata

Reply #2 –
Tag are always there and I got no problem in plugin version 2.3  My files got APEv2 tag and no ID3v1.  But yea why is ID3v1 there in the first place 

Anyway, when I open them up in foobar and choose Tagging > Rewrite file tags, the file are display correctly in version 2.4.  What had change? What the heck did foobar do to them? 

I don't want to rewrite all the tags thou cause that would change the crc & md5 I created for the album archived.

winamp couldn't read metadata

Reply #3 –
WavPack includes CRC checks by default. an MD5 result of the audio data is stored in there as well if you use the -m option on the wavpack encoder. not sure if it does this by default though.

winamp couldn't read metadata

Reply #4 –
Do you know how to check CRC or MD5 inside them if it correct and not corrupt.

winamp couldn't read metadata

Reply #6 –
Quote from: Mangix on
WavPack includes CRC checks by default. an MD5 result of the audio data is stored in there as well if you use the -m option on the wavpack encoder. not sure if it does this by default though.
Not by default, gotta use the -m switch.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

winamp couldn't read metadata

Reply #7 –
Wow!!! That little neat program rox!  All files check out OK.  I guess I can go re-write all the tag in foobar now.  Thank all.

P.S. I still hope to see Bryant explain why it display differently thou.

winamp couldn't read metadata

Reply #8 –
Quote from: hynunpoom on
Wow!!! That little neat program rox!  All files check out OK.  I guess I can go re-write all the tag in foobar now.  Thank all.

P.S. I still hope to see Bryant explain why it display differently thou.

I'm not exactly sure why you're seeing what you are seeing, but it turns out there was a change in the way tags were read in the winamp plugin. The change was actually made with the 4.31 library (see changelog) but I didn't rebuild the winamp plugin then so the change didn't show up until now (which is why I forgot to include in the winamp section).

Anyway, the difference is that the tag reading code will find an APEv2 tag even if there's an ID3v1 tag after it. Before, I simply looked for one or the other at the end of the file. But then I realized that if someone puts an ID3v1 tag on a WavPack file that already has an APEv2 tag on there, then they lose the [much better] APEv2 tag. This happens to people with EAC often who forget to uncheck the "add ID3 tag" button. Of course, a lot of the time they don't even realize it because the information might be the same!

BTW, I support ID3v1 for legacy reasons. A lot of old WavPack files have them (from before APEv2 even existed).

If running everything through foobar2000 works fine, then that's probably the way to go. This still doesn't explain why your seeing what your seeing though. Perhaps those files have some sort of corrupt APEv2 tag (or an APEv1 tag) that the old code accepted and the new code doesn't because I added some additional checking when I put in the logic to look past the ID3v1 tag.

If you have a [fairly short] file that the old winamp plugin sees a tag on and the new winamp plugin doesn't, I could take a look at it. It should be trivial to see what's going on.

Thanks,
David

winamp couldn't read metadata

Reply #9 –
David, i read http://www.wavpack.com/WavPack.pdf and got a lot, and i want to read that whole .pdf file, not only WavPack part, could you help me? Thanks a lot

winamp couldn't read metadata

Reply #11 –
Thanks for the explanation Bryant.

I can re-produce this problem with the program call Tag&Rename 3.2.  This program let me get tag from filename or vice versa which make my life easier so I'm been using it for sometime. 

Anyway, here is a copy the of file winamp can't read the tag and a corrected one using a simple 'rewrite tag' from foobar to fix it.  I compare both tag in foobar and couldn't find a single different between both tags.  Very weird.

winamp couldn't read metadata

Reply #12 –
Code: [Select]
C:\Documents and Settings\DARcode\My Documents\My Downloads>wvunpack -ss "16. Menuet for EMMA (Piano solo) [wrong tag].wv

 WVUNPACK  Hybrid Lossless Audio Decompressor  Win32 Version 4.40.0
 Copyright (c) 1998 - 2006 Conifer Software.  All Rights Reserved.


file name:         16. Menuet for EMMA (Piano solo) [wrong tag].wv
file size:         7035676 bytes
source:            16-bit ints at 44100 Hz
channels:          2 (stereo)
duration:          0:01:58.37
modalities:        lossless, very high
compression:       66.31%
ave bitrate:       475 kbps
encoder version:   4
original md5:      9af8537d24f24d1bd1ce0a0cc4c5d08c
file wrapper:      44 byte RIFF header

C:\Documents and Settings\DARcode\My Documents\My Downloads>wvunpack -ss "16. Menuet for EMMA (Piano solo) [correct tag].wv

 WVUNPACK  Hybrid Lossless Audio Decompressor  Win32 Version 4.40.0
 Copyright (c) 1998 - 2006 Conifer Software.  All Rights Reserved.


file name:         16. Menuet for EMMA (Piano solo) [correct tag].wv
file size:         7035708 bytes
source:            16-bit ints at 44100 Hz
channels:          2 (stereo)
duration:          0:01:58.37
modalities:        lossless, very high
compression:       66.31%
ave bitrate:       475 kbps
encoder version:   4
original md5:      9af8537d24f24d1bd1ce0a0cc4c5d08c
file wrapper:      44 byte RIFF header
APEv2 tag items:   4

Track = 16
Album = Victorian Romance Emma OST (Silhouette of a Breeze)
Artist = Ryo Kunihiko
Title = Menuet for EMMA (Piano solo)
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

winamp couldn't read metadata

Reply #13 –
Quote from: hynunpoom on
Thanks for the explanation Bryant.

I can re-produce this problem with the program call Tag&Rename 3.2.  This program let me get tag from filename or vice versa which make my life easier so I'm been using it for sometime. 

Anyway, here is a copy the of file winamp can't read the tag and a corrected one using a simple 'rewrite tag' from foobar to fix it.  I compare both tag in foobar and couldn't find a single different between both tags.  Very weird.

I figured out the problem. The APEv2 tag on the file that doesn't work has a bad header (tag_length = 0, should be = 182). The reason this worked before is because I added the validity check for the header when I changed the behavior of the tag loading code (normally you recognize a APEv2 tag by the footer, which in this case is fine). I assume that foobar2000 must not check the header either. Maybe this has been fixed in v3.3 (there's a comment about "many minor fixes" in the changelog).

It would be great if this was just the beta, but I really don't like to do an all-new release just to handle a badly formed tag. I think I'll just eliminate the check for the header altogether and do a quiet update when I get a free moment.

Thanks for finding this and taking the time to help me understand it. 

winamp couldn't read metadata

Reply #14 –
Quote from: bryant on
[...]It would be great if this was just the beta, but I really don't like to do an all-new release just to handle a badly formed tag. I think I'll just eliminate the check for the header altogether and do a quiet update when I get a free moment.
I don't see the problem in a 4.40.1 release, anyway could you please elaborate on the reason why you implemented the check for the APE tag header in the first place? I mean, you surely had a valid reason so isn't taking it out sacrificing robustness a bit? Not arguing by any means, simply trying to understand. Thanks for your time.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

winamp couldn't read metadata

Reply #15 –
Quote from: DARcode on
Quote from: bryant on
[...]It would be great if this was just the beta, but I really don't like to do an all-new release just to handle a badly formed tag. I think I'll just eliminate the check for the header altogether and do a quiet update when I get a free moment.
I don't see the problem in a 4.40.1 release, anyway could you please elaborate on the reason why you implemented the check for the APE tag header in the first place? I mean, you surely had a valid reason so isn't taking it out sacrificing robustness a bit? Not arguing by any means, simply trying to understand. Thanks for your time.

I think I should have added the check when I first implemented that function, but I was probably just being lazy. When I visited it again I was not feeling so lazy and did the "right" thing because, like you say, it should make the tag loading more robust because it is much less likely that the tag has been corrupted if both ends (the header and footer) are valid.

However, if nobody else is checking this then there might be many corrupt headers out there and my check is going to cause more trouble than it prevents. That's why I consider taking it out.

I would be very interested if the recent version of Tag & Rename has the same problem. That version 3.2 is over a year old and there have been many fixes since.

winamp couldn't read metadata

Reply #17 –
Quote from: bryant on
I figured out the problem. The APEv2 tag on the file that doesn't work has a bad header (tag_length = 0, should be = 182).

Can you tell me how to check this 'tag_length'?

Quote from: bryant on
I would be very interested if the recent version of Tag & Rename has the same problem. That version 3.2 is over a year old and there have been many fixes since.

Since you mentioned it. I went over there and download Tag&Rename v3.3 rc 1 (12/10/2006) their latest version out to date.  The result is unfortunately the same as before, still corrupt tag.  I guess "many minor fixes" on their changelog doesn't fix this .  But seriously thou, they didn't mention anything about WavPack since 3.2 (that's also the reason why I didn't try their update release before).

And about the header.  Does Monkey's audio(or other format that use APEv2) decoder plugin have validity check for the header?  If it had, then you probably did the right thing by implement in WavPack plugin.

winamp couldn't read metadata

Reply #18 –
Quote from: bryant on
Quote from: hynunpoom on

Thanks for the explanation Bryant.

I can re-produce this problem with the program call Tag&Rename 3.2.  This program let me get tag from filename or vice versa which make my life easier so I'm been using it for sometime. 

Anyway, here is a copy the of file winamp can't read the tag and a corrected one using a simple 'rewrite tag' from foobar to fix it.  I compare both tag in foobar and couldn't find a single different between both tags.  Very weird.

I figured out the problem. The APEv2 tag on the file that doesn't work has a bad header (tag_length = 0, should be = 182). The reason this worked before is because I added the validity check for the header when I changed the behavior of the tag loading code (normally you recognize a APEv2 tag by the footer, which in this case is fine). I assume that foobar2000 must not check the header either. Maybe this has been fixed in v3.3 (there's a comment about "many minor fixes" in the changelog).



Tag&Rename just released version 3.30 that fixes this issue.  I just tested it against the Winamp plugin and it works as expected.  They even listed it in the WhatsNew.txt file with the release.  So now all is right with the world. 
FLAC -8 | MP3 V2

winamp couldn't read metadata

Reply #19 –
Just in case someone has missed it, the freeware MS Windows Explorer shell extension plugin AudioShell (from the same company which develops Tag&Rename) has been fixed too:

Code: [Select]
AudioShell v.1.3 (02/01/2006)
- fixed bug when AudioShell write incorrect flags into APEv2 tag header and footer


Get it here: http://www.softpointer.com/downloads/AudioShell135.exe
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

winamp couldn't read metadata

Reply #20 –
Quote from: bryant on
Quote from: DARcode on

Quote from: bryant on
[...]It would be great if this was just the beta, but I really don't like to do an all-new release just to handle a badly formed tag. I think I'll just eliminate the check for the header altogether and do a quiet update when I get a free moment.
I don't see the problem in a 4.40.1 release, anyway could you please elaborate on the reason why you implemented the check for the APE tag header in the first place? I mean, you surely had a valid reason so isn't taking it out sacrificing robustness a bit? Not arguing by any means, simply trying to understand. Thanks for your time.

I think I should have added the check when I first implemented that function, but I was probably just being lazy. When I visited it again I was not feeling so lazy and did the "right" thing because, like you say, it should make the tag loading more robust because it is much less likely that the tag has been corrupted if both ends (the header and footer) are valid.

However, if nobody else is checking this then there might be many corrupt headers out there and my check is going to cause more trouble than it prevents. That's why I consider taking it out.

I would be very interested if the recent version of Tag & Rename has the same problem. That version 3.2 is over a year old and there have been many fixes since.

I am just working on APEv2 support for TAK and i have also the habit to implement as many validity checks as possible... Currently i am also checking the consistency of header and footer. Possibly a bad idea in the light of your post. I am curious: Have you removed your check?

winamp couldn't read metadata

Reply #21 –
No. Once the offending program was fixed I figured there was no need.

And I agree with you that more robust is better...