Closed GoogleCodeExporter closed 8 years ago
I will have a look!
Original comment by svollbehr
on 25 May 2011 at 2:58
Hm, I must be missing something as I cannot reproduce your error. I tried your
code and it worked just fine with latest revision in trunk. Also, version 1.8.1
did not make any changes to Zend_Media_Mpeg_Abs family of classes; it only
changed ID3v2 handling. Zend_Media_Mpeg_Abs only uses Zend_Media_Id3v2 class to
check whether it contains a tag in order to skip it. You're file doesn't have a
tag so that shouldn't be the problem.
I don't say you do not have a problem -- obviously something is wrong. However,
the file you uploaded did have the MPEG frame sync present. The
Zend_Media_Mpeg_Abs code is identical between 1.8 and 1.8.1. I also tried my
sample code to produce a bitrate chart and that produced the following.
http://chart.apis.google.com/chart?cht=lc&chs=800x375&chco=76a4fb&chls=2.0&chd=s
:YVYVVlfffYfffffflflfYflffVfrlffYfYf9rrffllrlllllfflflllllllllllllffllllffllflll
l9lrlllrrllllllffflflllfllflffrllfllrrllrrrlrrlfllfrlfllffllllrlrxrlfflllflllrxr
lrfffrlrrxlrlflxlrrllll9lflllllrllrlflrlrllrrxllffrrlrrrxrrrlflllllrlllrrrlrrl9f
llfrxlrlx9flfrlrlxllrfflxrllxlrllfrxrllxxrrlrlflll9fllfllrrlf9llrllllxfl9rrllllr
xflrlrllfrlrlllffflrrlxlrlrrffrlr9lrlrrlf9lfrlflfxlfrYfxfYl9rfllffflfrllfllllfll
llllllrrllflr9lllllxrrllxflllxrl9xrxxlrflrlxlrxlllxrllllrlffllflrxrflllrxlllrlrl
flrrxfrxrxflrrx9llfrlllllllflrlflfrlllfllrlfflllxllrlrflllrxfllffllrrrflrxlllllr
rxlllllrlxlfflfxflflllrlfrlfxrflfflrfllllxfrllllflllllfxflllrfrlllflfff9flrrflfr
llfllxfffllfflflrl9lllrlxrrfrfrlrrflllrllxrlllllrlllllfllfrfllfllflxlrlllflrlfll
lfflxrfrlrllllflfllflflffxfflfllllf9fllllfl9flxlllflll9lflffrlxflrllrffflrllrllf
lllllflxflllrllrllxlflllffllfrfffllfflflrfflflrlrfrrfflr9lf9lllrfflrfllflrllfflf
lffllllllflllflfG&chds=0,320&chtt=Bitrate+Graph&chts=808080,20&chxt=x,y,r,x,y&ch
xl=1:|0|32|40|48|56|64|80|96|112|128|160|192|224|256|320|2:|min|average|max|3:|F
rames|4:|Bit+Rate&chxr=0,0,2689|1,0,320|2,0,320&chxp=1,0,32,40,48,56,64,80,96,11
2,128,160,192,224,256,320|2,32,196.46262551134,320&chxs=2,505050,13,-1,t,bb0000&
chxtc=2,-1000&chma=10,10,10,10
Sorry I couldn't be of greater help here!
Original comment by svollbehr
on 3 Jun 2011 at 5:01
I'm experiencing the same problems - I tried 5 totally different MP3 files, and
all produced the same MPEG Audio Bit Stream exception. Something has to be
wrong here?
Original comment by stephan....@gmail.com
on 22 Jul 2011 at 2:40
Can you please provide me with an MP3 file and sample code block that
reprocudes the error? Also provide me with PHP version info.
Original comment by svollbehr
on 22 Jul 2011 at 2:43
Still having the issue.
Will provide you a test file via email.
Error occurs on my MacBook and on our Debian Servers (32bit and 64bit).
Original comment by stephan....@gmail.com
on 11 Oct 2011 at 4:32
I did some further research.
Since the exception is thrown in Zend_Media_Mpeg_Abs_Frame, I started looking
there.
The test that results in the exception is the following:
if (!Zend_Bit_Twiddling::testAllBits(Zend_Bit_Twiddling::getValue($header, 21, 32), 0xffe)) {
So I put this debugging code before the if:
echo decbin($header).PHP_EOL;
echo 0xffe.PHP_EOL;
echo decbin(0xffe).PHP_EOL;
$x = Zend_Bit_Twiddling::getValue($header, 21, 32);
echo $x.PHP_EOL;
echo decbin($x).PHP_EOL;
Output.
11111111111110111001000001100100
4094
111111111110
2047
11111111111
As you can see, the result of getValue() is one bit short.
So I think it should be Zend_Bit_Twiddling::getValue($header, 20, 32) instead
of 21.
After this change everything works fine here.
Original comment by stephan....@gmail.com
on 12 Oct 2011 at 9:49
Could you provide me with your exact PHP version?
Original comment by svollbehr
on 14 Oct 2011 at 11:27
I tried with PHP 5.3.6 and 5.3.2
Original comment by olaf.van...@gmail.com
on 14 Oct 2011 at 11:32
With attached file (file.mp3) ABS skips reader to 18658 (bytes offset), but if
I change setOffset($offset) to setOffset(28169) on line 151 - everything starts
to work. So I guess, there is a defect while calculating ID3 header size.
I've opened file with HxD (hex viewer), on 18658 offset there are lots of 0x00
bytes, some 0x55 and garbage. Also, 28169 has 0xFFFB beginning (saw this in
several files), dunno if it means something.
The worst thing is that this problem persist with half of my music library, so
I'll stay investigating what's going on here.
Original comment by mfthe...@gmail.com
on 3 Mar 2012 at 10:10
I actually got a fatal error running the sample code with your file.mp3 with
5.3.2: Uncaught exception 'Zend_Media_Mpeg_Exception' with message 'File does
not contain a valid MPEG Audio Bit Stream (Invalid frame sync)' in
...\php-reader\src\Zend\Media\Mpeg\Abs\Frame.php:236. What version of the
library are you using?
Anyways, something wrong there. The validation program I use also shows that
the frame sync does not start after the ID3, ie the file contains a stream
error.
Analyzing file "..\file.mp3"...
WARNING: "..\file.mp3" (offset 0x48e2): MPEG stream error, resynchronized
successfully
INFO: "..\file.mp3": 9061 MPEG frames (MPEG 1 Layer III), +ID3v1+ID3v2, CBR
Most players will skip data until they find another sync frame. Let me see what
I can do about that in the library.
Original comment by svollbehr
on 5 Mar 2012 at 7:32
On line 236 of Frame.php an exception is thrown because there is a stream
error. The better approach would of course be to find next sync frame and
ignore the garbage.
I did just implement a trivial resynchronization support in the class to get
pass this problem. Could you please check out the latest sources from
subversion repo and try the it to see if it works the way you'd expect.
Original comment by svollbehr
on 5 Mar 2012 at 8:46
Original comment by svollbehr
on 5 Mar 2012 at 8:55
>What version of the library are you using?
I used zipped one and other from subversion, both produced the same.
But now the problem has gone.
Thank you.
Original comment by mfthe...@gmail.com
on 8 Mar 2012 at 6:02
Original issue reported on code.google.com by
olaf.van...@gmail.com
on 25 May 2011 at 8:16