mutagen.mp3.HeaderNotFoundError: can't sync to an MPEG frame

[GoogleCodeExporter]

When I try running 'oggify -o mp3 "dir" ~1/"dir" I get the following errors:

Encoding 
Close_Encounters_Of_The_Third_Kind_[Collector's_Edition]/01-Opening:_Let_There_B
e_Light.flac to 
/tmp/2011-04-08.1/John_Williams/Close_Encounters_Of_The_Third_Kind_[Collector's_
Edition]/01-Opening:_Let_There_Be_Light.mp3
Traceback (most recent call last):
  File "/usr/local/bin/oggify", line 171, in <module>
    sys.exit(main())
  File "/usr/local/bin/oggify", line 151, in main
    oggify.encode(not options.pretend)
  File "/usr/local/lib/python2.6/dist-packages/oggify/__init__.py", line 117, in encode
    self.encode_file(src, dst)
  File "/usr/local/lib/python2.6/dist-packages/oggify/__init__.py", line 105, in encode_file
    self._encoder.set_tags(dst, self._decoder.get_tags(src))
  File "/usr/local/lib/python2.6/dist-packages/oggify/plugins/mp3.py", line 72, in set_tags
    mp3_tags = tag(file)
  File "/usr/local/lib/python2.6/dist-packages/tag_wrapper/__init__.py", line 164, in tag
    tag = mutagen.File(filename)
  File "/usr/lib/pymodules/python2.6/mutagen/__init__.py", line 214, in File
    if score > 0: return Kind(filename)
  File "/usr/lib/pymodules/python2.6/mutagen/__init__.py", line 73, in __init__
    self.load(filename, *args, **kwargs)
  File "/usr/lib/pymodules/python2.6/mutagen/id3.py", line 1990, in load
    self.info = self._Info(fileobj, offset)
  File "/usr/lib/pymodules/python2.6/mutagen/mp3.py", line 103, in __init__
    self.__try(fileobj, offset, size - offset, False)
  File "/usr/lib/pymodules/python2.6/mutagen/mp3.py", line 140, in __try
    raise HeaderNotFoundError("can't sync to an MPEG frame")
mutagen.mp3.HeaderNotFoundError: can't sync to an MPEG frame

This sounds like mutagen is having a problem.  The resulting file is zero 
length and it stops on the first file.  If I run the command again the next 
file is picked up for processing and the command dies the same way with the 
smae result that the next file created is zero length.

I'm running under Debian 6.0.1, mutagen is 1.19-2.

Thanks for your time.
bill p.

Original issue reported on code.google.com by wape...@gmail.com on 9 Apr 2011 at 11:37

[GoogleCodeExporter]

I'm sorry, this was not meant as a enhancement but is a bug.  I didn't see that 
a type needed to be set.

Original comment by wape...@gmail.com on 9 Apr 2011 at 11:40

[GoogleCodeExporter]

Can you supply a copy of the file it's getting stuck on - ideally the whole 
thing, but if that's not possible, the first 128KB or so? If you'd rather not 
post it here you can email it to joe.wreschnig at gmail.com.

That error occurs when Mutagen decides that the file is an MP3 file - which it 
did because it ended in .mp3 - but then the MP3 parsing code can't actually 
figure out how to load it.

Original comment by joe.wreschnig@gmail.com on 9 Apr 2011 at 5:39

[GoogleCodeExporter]

I sent a copy of the flac file to the requester but haven't heard anything 
back.  Any idea why mutagen (or oggify?) thinks a flac file is an mp3 file?  
Seems rather strange.

Original comment by wape...@gmail.com on 17 Apr 2011 at 12:02

[GoogleCodeExporter]

I didn't receive any email.

If the problem is in reading the FLAC rather than writing the MP3, it's 
possible that the FLAC has an ID3 tag. This is invalid, and it needs to be 
stripped; you can do that using the oneliner

from mutagen import id3; id3.delete("foo.flac")

Original comment by joe.wreschnig@gmail.com on 17 Apr 2011 at 11:45

[GoogleCodeExporter]

Honestly, rereading the original trace, it looks like oggify is generating a 0 
byte "MP3" and then expecting Mutagen to read it. That's a bug in oggify, not 
Mutagen.

Original comment by joe.wreschnig@gmail.com on 17 Apr 2011 at 11:47

[GoogleCodeExporter]

I'll try that first. I've no idea why a flac file would have id3 tags but I
can see why that would be a problem. Perhaps the ripping script changed
since the last version. I may need to change the command line to fix the
problem. Thanks for the help.

Original comment by wape...@gmail.com on 17 Apr 2011 at 12:49

[GoogleCodeExporter]

Original comment by joe.wreschnig@gmail.com on 15 May 2011 at 9:07

• Changed state: Invalid

[GoogleCodeExporter]

I did some checking on my system and found out that the libraries for the
mp3 support were incomplete.  It seems when you install a library you don't
get everything you should and have to install developer packages to get
header files.  In the modern day of terabyte drives we are worried about a
few kilobytes of header information.  Amazing.  Anyway, once I picked up the
mp3 headers via the developer libraries the applications started working.
The idea that oggify was sending a zero length file was the hint I needed to
track down the problem.  Perhaps oggify (and mutagen?) should indicate
missing formats (oggify: I have no idea what mp3 means or mutagen: null
input stream detected) to make this an easier problem to correct on the user
end.  In any case, thanks for the suggestion and I am sorry I didn't reply
sooner.  No excuse.

Thanks for the help.

Original comment by wape...@gmail.com on 16 May 2011 at 4:28