[Bug 727802] New: md5 checksum is missing from flac files encoded with encodebin

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=727802
  GStreamer | gst-plugins-base | 1.2.3

           Summary: md5 checksum is missing from flac files encoded with
                    encodebin
    Classification: Platform
           Product: GStreamer
           Version: 1.2.3
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: cfergeau at redhat.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Sound-Juicer uses encodebin to encode the files it rips. A bug report was filed
in fedora that the flac files it generates don't contain the stream md5
checksum which is used to verify that the file is not corrupt. This is
https://bugzilla.redhat.com/show_bug.cgi?id=961881
flac --test produces the error:
WARNING, cannot check MD5 signature since it was unset in the STREAMINFO

I've investigated this a bit, the MD5 signature is written by libFLAC in
update_metadata_() in src/libFLAC/stream_encoder.c using seek() and write()
vfuncs, which properly call back into gstflacenc.c. The seeking seems to work,
but the data never seems to get to the file sink to get written to disk.



I've been able to reproduce this using 'encoding' from gstreamer source:
(wav file came from http://www.nch.com.au/acm/11k16bitpcm.wav linked from
https://en.wikipedia.org/wiki/WAV but any random file should do the trick).

$ gst-plugins-base/tests/examples/encoding -f audio/x-flac -a audio/x-flac  -o
/home/teuf/output.flac file:///home/teuf/11k16bitpcm.wav

After that: (metaflac comes with the 'flac' package)

$ metaflac --list --block-number=0 /home/teuf/output.flac
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4608 samples
  maximum blocksize: 4608 samples
  minimum framesize: 0 bytes
  maximum framesize: 0 bytes
  sample_rate: 11025 Hz
  channels: 1
  bits-per-sample: 16
  total samples: 0
  MD5 signature: 00000000000000000000000000000000



If instead I do things manually with:

$ gst-launch-1.0 filesrc location=/home/teuf/11k16bitpcm.wav ! wavparse !
flacenc ! filesink location=/home/teuf/output.flac

$ metaflac --list --block-number=0 /home/teuf/output.flac
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4608 samples
  maximum blocksize: 4608 samples
  minimum framesize: 214 bytes
  maximum framesize: 7700 bytes
  sample_rate: 11025 Hz
  channels: 1
  bits-per-sample: 16
  total samples: 152267
  MD5 signature: 7ad725dd59f9d1f4bf6d50cf80aee75d

The minimum/maximum framesize should be written by libFLAC in the same way
(calls to seek/write vfuncs when the FLAC stream is finished). libFLAC also
tries to write seek tables when the stream is finished, but I haven't checked
whether they are impacted by this bug or not.

I've run the 'encoding' test with the 1.2 git branch, the gst-launch test has
been done with the fedora 20 packages (gstreamer 1.2.3)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.