flac dev - Feb 2013 - Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio

I'm using libflac on Windows to compress some audio samples. I'm
building the
library locally, using Visual Studio 2010. Each set of data is 2-5 MB and well
formed PCM encoded data. I'm finding some very odd behavior.

If I enable verify on the encode stream, I get a verify mismatch on most of my
sample sets. Each set of samples returns this error at a different location in
the stream, but always the same location for the same file.

However, if I disable verify, the resulting FLAC encoded data DOES decode
correctly in most cases, giving me an exact replica of the input.

In the other cases, one of the frames decodes into wrong data. I have not seen
more than one frame for a given set of data decode incorrectly; the frames
before and after it are correct. Sometimes the bad frame is partially correct,
or has many bytes that are close to the original. The bad frame's data is
always
the same, no matter how many times I try to re-encode the original file.

I've tried encoding and decoding these files with the FLAC command line
tool,
and it has no problems, so I think there might be an issue with my libflac 
binaries.

Has anyone encountered a similar problem, or are there any known issues that
could explain this?

El 07/02/13 19:07, Collin escribi?:
> I'm using libflac on Windows to compress some audio samples. I'm
building the
> library locally, using Visual Studio 2010. Each set of data is 2-5 MB and
well
> formed PCM encoded data. I'm finding some very odd behavior.
>
> If I enable verify on the encode stream, I get a verify mismatch on most of
my
> sample sets. Each set of samples returns this error at a different location
in
> the stream, but always the same location for the same file.
>
> However, if I disable verify, the resulting FLAC encoded data DOES decode
> correctly in most cases, giving me an exact replica of the input.
Before debugging further, ensure you can reproduce this in a different 
computer, or verify that you dont have broken RAM.

Cristian Rodr?guez wrote:
>> sample sets. Each set of samples returns this error at a different
location in
>> the stream, but always the same location for the same file.
>>
>> or has many bytes that are close to the original. The bad frame's
data is always
>> the same, no matter how many times I try to re-encode the original
file.
>
> Before debugging further, ensure you can reproduce this in a different
> computer, or verify that you dont have broken RAM.
Given that the errors occur at repeatable locations, broken RAM seems 
unlikely.

Collin wrote:
> Has anyone encountered a similar problem, or are there any known issues
that
> could explain this?
No known issues of this kind, but I would like to see a repeatable test
case so I can investigate further.

Cheers,
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

On 07-02-13 23:07, Collin wrote:
> I'm using libflac on Windows to compress some audio samples. I'm
building the
> library locally, using Visual Studio 2010. Each set of data is 2-5 MB and
well
> formed PCM encoded data. I'm finding some very odd behavior.
One of the main strengths of FLAC is that it has a pretty exhaustive 
test suite. Have you run it? It's the test_libFLAC part of the MSVC 
files. Furthermore, which version of libFLAC is it?

Are you calling
FLAC__stream_encoder_finish(encoder);
before you call
FLAC__stream_encoder_delete(encoder);

That would cause this issue.

-Ben Allison
> I'm using libflac on Windows to compress some audio samples. I'm
building
> the
> library locally, using Visual Studio 2010. Each set of data is 2-5 MB and
> well
> formed PCM encoded data. I'm finding some very odd behavior.
>
> If I enable verify on the encode stream, I get a verify mismatch on most
> of my
> sample sets. Each set of samples returns this error at a different
> location in
> the stream, but always the same location for the same file.
>
> However, if I disable verify, the resulting FLAC encoded data DOES decode
> correctly in most cases, giving me an exact replica of the input.
>
> In the other cases, one of the frames decodes into wrong data. I have not
> seen
> more than one frame for a given set of data decode incorrectly; the frames
> before and after it are correct. Sometimes the bad frame is partially
> correct,
> or has many bytes that are close to the original. The bad frame's data
is
> always
> the same, no matter how many times I try to re-encode the original file.
>
> I've tried encoding and decoding these files with the FLAC command line
> tool,
> and it has no problems, so I think there might be an issue with my libflac
> binaries.
>
> Has anyone encountered a similar problem, or are there any known issues
> that
> could explain this?
>
> _______________________________________________
> flac-dev mailing list
> flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>

Erik de Castro Lopo <mle+la <at> mega-nerd.com> writes:
> 
> Collin wrote:
> 
> > Has anyone encountered a similar problem, or are there any known
issues that
> > could explain this?
> 
> No known issues of this kind, but I would like to see a repeatable test
> case so I can investigate further.
> 
> Cheers,
> Erik

It turns out it was an error on my part; sorry for the trouble. I misunderstood
the format libflac was expecting my samples in. I found the wording in the
documentation very confusing.

My audio file has 2 channels and 16-bit samples, so I have to pull out each
individual sample, push it into a FLAC__int32, and fix endian-ness before I can
pass it to libflac.

The documentation made me think that libflac just wanted me to shove my 2-byte
sample into a FLAC__int32. I wasn't aware that it wanted me to extend the
sign,
as well.