Re: Problem with RIFF tags in audio ripped with WMP11 x64
- From: Benjatado <Benjatado@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 20 Feb 2008 08:03:01 -0800
I am getting the same file header format errors here when I rip to wav using
WMP11! I have looked at the header of these file and see a distinct
difference in the WMP11 RIFF tags here from the RIFF tag headers ripped using
non-WMP11 and those RIFF tag headers generated from WMP11.
Here are the RIFF tag headers of each:
Non-WMP11 ripped WAV RIFF tag header:
"RIFF¤¤¤¤WAVEfmt...."
WMP11 ripped WAV RIFF tag header:
"RIFF¤¤¤¤WAVELIST..."
This WAVEfmt vs. WAVELIST difference I believe has caused problems in some
of my audio apps because it does not appear to know what to do when it
encounters the WAVELIST RIFF tag header WMP11 writes, apart from the way the
WAVEfmt RIFF tag header appears on the "valid" wav file.
Furthermore the WMP11 ripped file headers have many other tag headers than
the non-WMP11 ripped tag header. Such as INFOIART, INAM, IPRD, IGNR, ITOC,
ITRK. This ITRK is interesting because it lists "ITRK¤¤¤4¤fmt..." So I am
guessing this ITRK tag sets a value of 4 for the "Track"... but then look...I
wonder what this "fmt" value is sitting out here all alone? Looks like
another format value...like in the "valid" WAVEfmt RIFF tag wav header! Oh,
maybe this is the issue!?
WAVEfmt on the valid.... WAVLIST on the invalid. Looks like the LIST tag its
crew of tag-a-longs are cutting in on the WAVEfmt before the "fmt" value has
been set.
Just guess here...I don't know...but surely someone does...?
Hopefully someone can shed some light on these RIFF tag WMP11 discrepancies
here.
Check out ( http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm
) for a hex editor app that will let you see the wav file headers.
-b
"PC Pete" wrote:
Thanks for taking the time to respond, Neil..
Neil Smith [MVP Digital Media] wrote:
This is a peer supported newsgroup, so there's no "moderator" nor isI understand that the forums aren't a paid or high-priority support
there any expectation that answers can be provided in a given time
frame.
It happens your post has coincided with a massive drop in newsgroup
volume, which I suspect is caused by a broken web interface to the
newsgroup, so it's likely that very few people have actually been able
to respond even if they knew the answer to your well argued (but
highly technical) question and resolution tests.
mechanism. I was just a little worried my question had been overlooked
(which is unlikely given the dedication of most helpers here).
OK so it's not a problem I've ever tested or am able to test in theI understand this is definitely a corner case, both from the WMP and the
specific environment you quoted (WMP11/64). However the behaviour
would be expected to be the same in WMP11/32 so I can at least look
around for ideas.
There have always been some issues of instability or incompatibility
between various applications use of tagging, particularly in MP3
though I don't think very many people use raw WAV (i.e. it's an edge
case) so the number of active testers in any case would be low.
player (Helium Music Manager 2007) side of things. Who uses WAV/BWF/RF64
these days outside of the big production studios? And not even there
sometimes. So I'm "special" ;)
There's recently been a new feedback loop introduced for MVPs so I'mThat would be a great idea. I can provide any header data you might
willing to put the complete problem report into that and see if
anything comes back - it could be weeks realistically before any
resolution or detail is made available even then.
need, without having to upload hundreds of megs of audio. And time isn't
a real big problem at the moment, despite my wailing about no response
earlier. It will become important in the coming months, but right now I
just need to know that this is being investigated. And fixed.
One or 2 things to clarify is the other players you mentioned - whichThe only player that has this trouble is Helium Music Manager 2007. I'm
ones are they, and do they do any form of autoupdate to the files ?
working with the developers, and they have bent over backwards trying to
figure out why their player breaks on WMP ripped tracks, and ONLY on WMP
ripped tracks. They have stated that they don't do any kind of file
update under any circumstances for RIFF files - all that data is managed
in the database (MySQL).
They have rewritten their player code so that the non-standard WMP
metadata doesn't break their player, but although that has fixed the
problem on x32 machines, their fix doesn't appear to have fixed the
probem on the x64 setup I'm using.
In WMP, are the files also added to the library and monitored folders,The files are ripped and stored outside WMP - WMP doesn't run apart from
or are these files effectively isolated from the player library, other
than when actually played ?
the initial rip. I've just checked, and WMP did add the track references
to its library, but I haven't played or tested the files within WMP itself.
And I guess there may be a better place to post this after all that -I might take the problem up there, then. I understand this is probably a
the real hardcore experts on underlying format handling hang out on
the newsgroup microsoft.public.windowsmedia.sdk
That may be another avenue to explore.
bit too low-level/low-interest/corner case for the forum here. And since
it's a header format bug, the SDK folks might have more ideas. Thanks
for the suggestion.
Believe me, I know how much this looks like a simple player corrupting
the file problem! But I've got the developers pointing at the
badly-formed headers, and they're absolutely adamant that no file
modification takes place, so I'm
Thanks again for taking the time, I appreciate your ideas and suggestions.
HTHYes, it did! :)
-PCP
- Prev by Date: Re: page that comes up is blank
- Next by Date: Re: dvd download
- Previous by thread: Using WME with multiple sources
- Next by thread: Re: dvd download
- Index(es):
Relevant Pages
|
