in reply to Re^3: ID3v2 TAG Footer Reading goes wrong
in thread ID3v2 TAG Footer Reading goes wrong

To: Anonymous Monk,

Thanks for the suggestion and possible really interesting implementation to my code. While I was working with my code I came with another possible mistake that I trying to explain but for the moment not successfully. I noticed that the sync_safe process at the header:

$mp3_size = ($memory[0] & 0xFF) |
    (( $memory[1] & 0xFF ) << 7) |
    (( $memory[2] & 0xFF ) << 14) |
    (( $memory[3] & 0xFF ) << 21);

[download]

If I do print Dumper(@memory); before the sync_safe process, it will print out:

$VAR1 = 0;
$VAR2 = 0;
$VAR3 = 5;
$VAR4 = 59;

[download]

After the sync_safe process if I do print Dumper(@memory); again, it will print out:

$VAR1 = 123813888;

[download]

I am curious, I know that the sync_safe process is shifting 7 bits to the left of eac byte. So no I am comfused is it operating correctly? or am I doing something wrong?

Maybe I am missing something really basic here and this is the reason that I do not understand. Sorry for asking too many questions but since I am going through the learning curve process I have so many queries that I can not find information that will provide me a clear answer.

Thank you again for your time and effort.

Replies are listed 'Best First'.
Re^5: ID3v2 TAG Footer Reading goes wrong
by roboticus (Chancellor) on Jan 11, 2014 at 00:13 UTC

    thanos1983:

    Questions about manipulating binary numbers like that are often best solved by looking them over in binary. Using a little bit of perl:

    #!/usr/bin/perl
use strict;
use warnings;

my @memory = (0, 0, 5, 59);

print "Original values:\n";
printf "% 3u : %08b\n", $_, $_ for @memory;

$memory[1] = $memory[1] << 7;
$memory[2] = $memory[2] << 14;
$memory[3] = $memory[3] << 21;
print "\nAfter shifting the values\n";
printf "% 10u : %032b\n", $_, $_ for @memory;

my $t = 0;
$t += $_ for @memory;
print "\nThe sum:\n";
printf "% 10u : %032b\n", $t, $t;

    [download]

    Running it gives a hopefully familiar number: ;^D

    Original values:
  0 : 00000000
  0 : 00000000
  5 : 00000101
 59 : 00111011

After shifting the values
         0 : 00000000000000000000000000000000
         0 : 00000000000000000000000000000000
     81920 : 00000000000000010100000000000000
 123731968 : 00000111011000000000000000000000

The sum:
 123813888 : 00000111011000010100000000000000

    [download]

    Update: I just read the thread, and noticed that in your code, you use the same construct several times. Additionally, you mention that you only want seven bits. So I'd suggest writing a subroutine that masks off the high bit of your bytes and packs the number for you. Something like the following, but with a better name:

    sub plonk {
    my ($b0, $b1, $b2, $b3) = @_;
    return     $b0 & 0x7f
            + ($b1 & 0x7f) << 7
            + ($b2 & 0x7f) << 14
            + ($b3 & 0x7f) << 21;
}

    [download]

    ...roboticus

    When your only tool is a hammer, all problems look like your thumb.

[reply]
[d/l]
[select]
Re^5: ID3v2 TAG Footer Reading goes wrong
by no_slogan (Deacon) on Jan 11, 2014 at 01:11 UTC
    ID3 uses big-endian byte order (high byte first), so you've got them backwards. Also, think about using a sub, like roboticus says.
[reply]

In Section Seekers of Perl Wisdom