Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 3 of 3

Thread: More WMA fixes

  1. #1
    John Harding
    Guest

    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.

  2. #2
    John Harding
    Guest

    More WMA fixes

    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.
    >
    >

  3. #3
    Dan Sully
    Guest

    More WMA fixes

    * 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •