LAME header not parsed correctly for LAME version 3.100

[mogwa1]

The LAME header for mp3 encoded with version 3.100 is not parsed correctly.

Looking at the code, this seems to be the caused by the check whether the LAME version string is greater or equal to "LAME3.90". Since "LAME3.100" < "LAME3.90", the headers for 3.100 are treated like pre 3.90-headers.
One side effect is that the long_version string contains 11 extra bytes of undefined data. This is causing problems in at least one project (OMPD) which is using getID3 and is storing the data in a database. Because of the undefined extra characters, this is making SQL queries fail.
See ArturSierzant/OMPD#98 .

[JamesHeinrich]

Fixed in eafd655

[toto4ds]

hello,
this patch get PHP Notice: Undefined offset: 1 for some files.
var_dump($thisfile_mpeg_audio_lame); show:
array(4) { ["long_version"]=> string(20) "LAME© nx\É" ["short_version"]=> string(9) "LAME© nx\" ["numeric_version"]=> string(5) "© nx\" ["integer_version"]=> array(1) { [0]=> int(0) } }

[JamesHeinrich]

Can you provide a sample file that shows this problem?

[toto4ds]

https://drive.google.com/drive/folders/1CJLJDLV5-Hw_gDbvu64p8u_uHOIhjc7H?usp=sharing

[JamesHeinrich]

Do you know which exact version of LAME was used to write this file? It seems to be storing an invalid LAME version string LAME© nx\É. When I create a test encode with LAME v3.100.1 it stores the version string in the expected format: LAME3.100 (and LAME3.100.1 in the footer).

I have modified the code 6dcbca8 to do more checking that the version string is in the expected format, the errors should be gone now.

[toto4ds]

Unfortunately no. This is a very very old file.