closes #163

In MP3Parser, I noticed the logic to jump to the next bytes was wrong (99% sure of that).

To debug it, I added a puts in the method parse_mpeg_frames:

seek_jmp = sync_bytes_offset_in_4_byte_seq(four_bytes)
puts "frame: #{frame_i}, pos: #{io.pos-4}, pos(h): #{(io.pos-4).to_s(16)} four: #{four_bytes}, hexa: #{four_bytes.map {|ii| ii.to_s(16)} }, jump: #{seek_jmp}"
if seek_jmp > 0
  io.seek(io.pos - 0 + seek_jmp)
  next
end

Then I got this:

frame: 183, pos: 1474, pos(h): 5c2 four: [0, 255, 251, 148], hexa: ["0", "ff", "fb", "94"], jump: 1
frame: 184, pos: 1479, pos(h): 5c7 four: [0, 0, 0, 0], hexa: ["0", "0", "0", "0"], jump: 4

The correct would be jumping to 1475, but it jumped +4 because it didn't take into account the 4 bytes that were already read at the beginning of this method:

# lib/parsers/mp3_parser.rb:139
data = io.read(4)

I fixed to subtract this 4 bytes, like this:

if seek_jmp > 0
  io.seek(io.pos - 4 + seek_jmp)
  next
end

And the result was:

frame: 366, pos: 1474, pos(h): 5c2 four: [0, 255, 251, 148], hexa: ["0", "ff", "fb", "94"], jump: 1
frame: 367, pos: 1475, pos(h): 5c3 four: [255, 251, 148, 196], hexa: ["ff", "fb", "94", "c4"], jump: 0

Because of that, it was possible to read the frames correctly!

I also needed to change MAX_FRAMES_TO_SCAN to a greater value, otherwise, it wouldn't reach this point.

Attention!

With this modification, the test #parse_http is called with hash options in spec/remote_fetching_spec.rb started to fail because it started to recognize the file PNG/anim.png as an mp3 as well!

I'm not sure if this behaviour can cause new bugs, wdyt?

Question

This file was authorized by the owner to use as an example. Should I mention his name in somewhere?` (I created a fixture file by myself)