Missing metadata occasionally

[GoogleCodeExporter]

What steps will reproduce the problem?

1. using the program with certain (non-compliant?) flac files e.g. 
./flac2all_v3.28.py mp3 flacdir/ -c -o MP3dir
2.
3.

What is the expected output? What do you see instead?

The output files have no tags other than LAME automatic setting the genre tag 
to "Other".

What version of the product are you using? On what operating system?

v3.28 on Debian Wheezy

Please provide any additional information below.

The fix for me was to remove the "--block-number 2" argument to metaflac. It 
doesn't seem to be causing any other problems that I can see.

Here is the metaflac output for 1 affected file:

$ metaflac --list ../Music/Midge\ Marsden/Burning\ Rain/01.\ Burning\ Rain.flac 
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 1152 samples
  maximum blocksize: 1152 samples
  minimum framesize: 14 bytes
  maximum framesize: 4555 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 10054212
  MD5 signature: af24d2c3f4afbd0802b723bb4302ed5c
METADATA block #1
  type: 4 (VORBIS_COMMENT)
  is last: false
  length: 219
  vendor string: reference libFLAC 1.2.1 20070917
  comments: 9
    comment[0]: TITLE=Burning Rain
    comment[1]: ARTIST=Midge Marsden
    comment[2]: ALBUM=Burning Rain
    comment[3]: DATE=1991
    comment[4]: TRACKNUMBER=01
    comment[5]: TRACKTOTAL=18
    comment[6]: GENRE=R&B
    comment[7]: METADATAPROVIDER=User
    comment[8]: graphic_front_cover+=
METADATA block #2
  type: 1 (PADDING)
  is last: true
  length: 210

Original issue reported on code.google.com by pivotman...@gmail.com on 24 Sep 2013 at 4:04

[GoogleCodeExporter]

Hmm, I will have to investigate this further. I remember adding the 
"--block-number 2" to it because that is where the metadata was stored on all 
the test files I used. I don't want to fix this bug and break it for everyone 
else :)

Original comment by i...@ziva-vatra.com on 2 Nov 2013 at 7:06

[GoogleCodeExporter]

Right, removing "--block-number 2" is not a long term fix, because the other 
blocks may confuse the metadata parser. 

Also, block number 2 seems to be the default block used for Vorbis comments by 
the reference FLAC encoder, but from what I see there is no requirements for 
this to be fixed. As long as the block type is "VORBIS COMMENT" it is valid. 
Could be that other encoders don't put it in that block.

Either way, a better way of detecting Vorbis comment blocks will be needed. 

Original comment by i...@ziva-vatra.com on 2 Nov 2013 at 8:05

• Changed state: Accepted

[GoogleCodeExporter]

Fair enough and thanks. Looking at http://xiph.org/flac/format.html suggests 
that the STREAMINFO metadata block must be the first metadata block, followed 
by zero or more other metadata blocks, in no particular order. That certainly 
mirrors what I've seen with the different versions of flac encoders over the 
years.

I've attached a patch so that the scanner only starts looking for comment tags 
within a "Type 4 Vorbis Comment" metablock. That will prevent comment tags in 
other metablock types from poisoning the track tags. This is my first foray 
into Python so if the code looks amateurish, that's because it is!

Original comment by pivotman...@gmail.com on 3 Nov 2013 at 11:27

Attachments:

• patch.diff

[GoogleCodeExporter]

Thank you very much for the code patch! I have integrated it into the current 
stable version. Please can you check out revision 37 and make sure it works ( I 
will do the same in the coming days as well). 

Original comment by i...@ziva-vatra.com on 7 Dec 2013 at 9:29

• Changed state: Fixed