PDA

View Full Version : More WMA fixes



John Harding
2004-02-18, 07:16
I noticed that my WMA albums weren't being properly sorted by tracknumber,
so I decided to take a look.
Although the Windows Media SDK claims that the WM/TrackNumber field is
supposed to be a string, it
notes that parsers should be prepared for it to be a DWORD (32-bit unsigned
value) instead. Took a look
at what was coming out of my media files, ripped with Windows Media Player,
and sure enough - they were
DWORDs instead of strings.
My fix was just to convert the track number inside CPAN::Audio::Wma.pm when
it's putting entries from the
Extended Content Description object into the COMMENTS hash as follows:

if( $name =~ 'TrackNumber' )
{
print "Converting WM/TrackNumber from $v->{'value'} to " .
ord($v->{'value'}) . "\n";
$v->{'value'} = ord($v->{'value'});
}

It should probably be cleaned up to check for both strings and DWORDs,
instead of just blindly
assuming it's a DWORD. Alternately, logic could be put into
CleanTrackNumber in info.pm to handle
binary track numbers. The trick is when you get a track number high enough
that the binary value corresponds
to a valid ascii number. It might be necessary to do the conversion when
reading the value rom the ECD object.

I'll see if I can get a more robust solution done later today and update.
In the meantime, if someone has WMA
tracks that DO properly get sorted by tracknumber, could you send me one?
I'd like to test my changes with
DWORD-based tracknumbers as well as string-based tracknumbers, since the
spec indicates to expect either.

John Harding
2004-02-18, 10:25
Found a better way to fix this - I hadn't realized that entries in the
extended content description object specify what format their value is in.
The code in CPAN::Audio::wma.pm was already parsing out the value type, it
just wasn't using it to determine what to do with the value data, and was
always treating it as a string. Fairly simple fix to unpack appropriate
data types.
What's the appropriate process for submitting the code for bug fixes?
My modified version of CPAN::Audio::wma.pm is available at
http://john.harding.name/wma.pm


----- Original Message -----
From: "John Harding" <john_squeezebox (AT) john (DOT) harding.name>
To: <discuss (AT) lists (DOT) slimdevices.com>
Sent: Wednesday, February 18, 2004 6:16 AM
Subject: [slim] More WMA fixes


> I noticed that my WMA albums weren't being properly sorted by tracknumber,
> so I decided to take a look.
> Although the Windows Media SDK claims that the WM/TrackNumber field is
> supposed to be a string, it
> notes that parsers should be prepared for it to be a DWORD (32-bit
unsigned
> value) instead. Took a look
> at what was coming out of my media files, ripped with Windows Media
Player,
> and sure enough - they were
> DWORDs instead of strings.
> My fix was just to convert the track number inside CPAN::Audio::Wma.pm
when
> it's putting entries from the
> Extended Content Description object into the COMMENTS hash as follows:
>
> if( $name =~ 'TrackNumber' )
> {
> print "Converting WM/TrackNumber from $v->{'value'} to " .
> ord($v->{'value'}) . "\n";
> $v->{'value'} = ord($v->{'value'});
> }
>
> It should probably be cleaned up to check for both strings and DWORDs,
> instead of just blindly
> assuming it's a DWORD. Alternately, logic could be put into
> CleanTrackNumber in info.pm to handle
> binary track numbers. The trick is when you get a track number high
enough
> that the binary value corresponds
> to a valid ascii number. It might be necessary to do the conversion when
> reading the value rom the ECD object.
>
> I'll see if I can get a more robust solution done later today and update.
> In the meantime, if someone has WMA
> tracks that DO properly get sorted by tracknumber, could you send me one?
> I'd like to test my changes with
> DWORD-based tracknumbers as well as string-based tracknumbers, since the
> spec indicates to expect either.
>
>

Dan Sully
2004-02-18, 10:39
* John Harding <john_squeezebox (AT) john (DOT) harding.name> shaped the electrons to say...

>Found a better way to fix this - I hadn't realized that entries in the
>extended content description object specify what format their value is in.
>The code in CPAN::Audio::wma.pm was already parsing out the value type, it
>just wasn't using it to determine what to do with the value data, and was
>always treating it as a string. Fairly simple fix to unpack appropriate
>data types.
>What's the appropriate process for submitting the code for bug fixes?
>My modified version of CPAN::Audio::wma.pm is available at
>http://john.harding.name/wma.pm

John - can you please send me a diff -up Original.pm New.pm ?

Thanks.

-D
--
Work is what you do for others. Art is what you do for yourself.