|
A problem playing MP3 files edited with mpgedit using iTunes 6.0.2 has been found. The problem is known to occur with the latest release of iTunes, version 6.0.2, and constant bitrate (CBR) MP3 files encoded with LAME that have been joined together. The problem is iTunes only recognizes the length of the first segment of the joined MP3 file, instead of the length of the entire joined MP3 file. The problem is due to the prefixed "Info" frame added by LAME. Included since version 3.92 of LAME, this "Info" frame is added to CBR-encoded MP3 files, which is substituted in place of the Xing header included normally prefixed with VBR-encoded encoded files. When iTunes finds this frame occurring in the middle of an MP3 file, it believes the end of the file has been found, and stops playing the MP3 file at that location. This frame can be recognized by the fact it has a "main data begin" value of zero, which preceds the actual first frame of the segment, which also has a "main data begin" value of zero. Two frames in a row with a "main data begin" value of zero is not usual in the actual MP3 bitstream. The problem only occurs when joining MP3 files together, and the first frame of the joined files consists of the "Info" frame. It is believed that iTunes now assumes it has found the end of the file when the first "Info" frame occurring in the middle of the MP3 file is found. The length of files with this property appear only as long as the first file segment of the joined file. For example, take the case of the joined MP3 file, joined.mp3, which was created by appending these three MP3 files with mpgedit:
mpgedit -o joined.mp3 -e- first.mp3 second.mp3 final.mp3
Assume each file first.mp3, second.mp3 and final.mp3 are each 60 seconds long.
iTunes will represent the total length of joined.mp3 as only 60 seconds,
instead of 3 minutes as would be expected.
Edited files with this problem can be fixed with the fix main data begin Python script. This script works by searching the MP3 file for all occurrences of two consecutive frames with "main data begin" values of zero, and removes the first of the two frames. This problem can be avoided in the future when using LAME by encoding CBR files using --nogap LAME option. This option prevents prefixing the "Info" frame onto CBR files, or the Xing frame when VBR encoding files. Given this example:
lame --nogap test.wav
LAME will encode test.wav to the CBR-encoded MP3 file test.mp3. Be careful
when encoding with the --nogap option, as the output file name is merely the
input file basename with the mp3 extension. It is not possible to provide
an output file name on the command line with the --nogap option, just a
target directory using the --nogapout.
Thanks go to Jared Benedict and Public Radio Exchange for first bringing this issue to the attention of mpgedit. |