Skip to main content
Topic: FLAC bug? (Read 1108 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FLAC bug?

Hello,

I converted a PCM Wave file to FLAC using this command under Linux Mint:

$ flac -5 file.wav

So it compressed it to FLAC.

Then I imported the source file and the flac file into Audacity, flipped the polarity of one and mixed them together. If both are bit-identical, it will lead to a line of zeros.

But there is one sample NOT zero in the left channel. The FLAC and the source wave differs here. This is enough off to produce an audible click. This is not what I would call "lossless".

I'm very astonished about it and I get in doubt about the reliability in FLAC.

How did this happen? Bug?  :o

I tested the FLAC file using the -t parameter of the flac encoder and it says, that the file is OK.

The source is a regular, uncompressed stereo 16-Bit wav file with 22050 Hz of sample rate and was never compressed before.

I re-saved the source wav file before conversion to ensure the healthy of the source file. But it didn't change anything.

I used FLAC 1.3.2 for that. But, if I use 1.3.1, the difference is gone.  :o

Re: FLAC bug?

Reply #1
Code: [Select]
sha256sum file.wav

flac -5 file.wav

flac -d file.flac -o decoded.wav

sha256sum decoded.wav

Do the hashes from 1 and 4 match?  If so, it's not a problem with flac's reliability.

Re: FLAC bug?

Reply #2
My first thought is that maybe the .wav file is corrupted or incompliant? If so, then there is no "correct" way to read it, and two applications - even, two versions of the same - might choose different ways to produce a result.

Is the wrong sample at the beginning (or end), by the way? Idea: attempted-to-write-tag -> attempted-read-as-audio.

Re: FLAC bug?

Reply #3
Does mismatch.

file.wav: 68439de19ad37d0bf1e4ae13bd3af496b7f1b6d3467dd36c31af08f2669c4501
decoded.wav: c882df77994c96b7e09edc42b4f83913eabf0d6cdcc9a341228bf84d605e6ea2

@Porcus:
The wrong sample is somewhere in the middle. Exactly: Sample no. 492106

I tried to re-save it as-is using Audacity before encoding. Didn't help.

If one sample is corrupt, the bad sample would be already in the source file so both files will contain that bad sample.

The problem does not occur in FLAC 1.3.1.

Re: FLAC bug?

Reply #4
Can you upload this .flac file? And the original .wav file, too...

Re: FLAC bug?

Reply #5
No. Due to copyright laws, it is illegal in my country to do this.

Re: FLAC bug?

Reply #6
Understandable but this would only be for diagnostics and study  reporting a bug without provideing data is pointless no one can help you then :( for the record its not file-sharing if you trying to fix a problem with a audio player or codec the audio is kind of a pre requisite

Re: FLAC bug?

Reply #7
Quote
Understandable but this would only be for diagnostics and study

Still illegal here... I live in Germany.  ::)
Up- and downloading copyrighted music leads to very high penalties here. It doesn't matter if it is just for diagnostic purposes or not so in my case, it is indeed illegal file-sharing.

Keep using FLAC 1.3.1 is safer to me than breaking the copyright law  ;) .

Do you have the computer game "Anno 1602"? If so, you have the problematic audio file too. :)

Re: FLAC bug?

Reply #8
Is it possible to share only first 30 seconds? 492106/22050 = 22.3 seconds, so such file will contain the problematic place.

Re: FLAC bug?

Reply #9
Illegal too...

And I already tried to shorten it to ~100 samples with the problematic one in the center. But if I cut it, the issue doesn't appear anymore. It is already enough to remove a few samples in the beginning to "fix" the problem.

Re: FLAC bug?

Reply #10
I bought the game. No WAV file bundled there has sha256 checksum matching what you posted. Which file are you testing with?

Re: FLAC bug?

Reply #11
MUSIC8/Ocean Trip.wav

(The checksum was from a file I re-saved using Audacity to be sure that there is no corruption)

Edit:

No, It was the checksum from original wav file. This is correct :)

The file is 18.867.092 bytes in size and the game CD is in excellent condition.


Re: FLAC bug?

Reply #12
c11fd2e7d6763ed6a555c45f500e8b3a12ef64d33de1c1a3a7a1b57f2a23f513 ?SHA256*Ocean Trip.wav
My file is 4716818 bytes and file-command reports this: Ocean Trip.wav; RIFF (little-endian) data, WAVE audio, Microsoft PCM, 4 bit, stereo 22050 Hz
It's nothing but noise when opened in Audacity, foobar2000 reports constant errors when trying to play it. FLAC won't touch it.

Re: FLAC bug?

Reply #13
Oh... I barely remember....

Your copy is one of these newer releases where the add-ons are included, right?
Does the music play correctly in the game?
There was something wrong with the files of these editions (which is ignored by the game). I don't remember anymore.

But my "Ocean Trip" is from an old CD without the addons included.

Re: FLAC bug?

Reply #14
It occurs to me that the checksum procedure hashes the files as they exist on the drive, which includes any header information (wav is a container, after all), which will change subtly between [en|de]codings.

However, a cycle of flac encoding and decoding and then re-encoding the decoded file (and so on) always shows the same embedded MD5 checksum for the contained audio stream).

Additionally, if you extract the raw PCM stream from the original WAV and the decoded WAV, the checksums match.

Re: FLAC bug?

Reply #15
Oh... the header. I did the test again and exported to RAW using Audacity (yes, dither is turned off)

The checksums:
Source -> 85743a2ef8c919a7ad94ec703e6dedbfe23917d1e4a958090aaee6143dd0361b
Decoded -> ac11c211c3db35963e0cd784d6d18d443e089eec0ba8be1eee321a19cc63b013

BTW: It is the only file where it happens. All others I tried, are identical (so the checksums match for these)

Re: FLAC bug?

Reply #16
The common thread here seems to be Audacity; I can't reliably produce different PCM streams when using the command line only, but Audacity seems to output different PCM streams every time.

Re: FLAC bug?

Reply #17
Did you turn off the dither under Preferences -> Quality? (by default, it is on)

Besides that, these is an audible click after the conversion. It is not only the checksum that is different ;)

Re: FLAC bug?

Reply #18
I downloaded CD-image and the sound files are ADPCM compressed on it too. And the image is 748 MB in size, not much room for uncompressed WAVs that take four times more space.

I don't see this moving anywhere if you insist on being unable to share the file.

Re: FLAC bug?

Reply #19
My version is uncompressed (16-bit PCM and this is really inside the files, if I trust my hex editor). The music part of the game is around 280 MB. CD has a capacity up to 700MB. There is enough remaining space for the game left. And it is a CD, not DVD. :D

My file hasn't ADPCM noise at all. It is really 16-bit PCM.

I can't share the file by law.

Personally, I would provide it here, if I can. :D

Re: FLAC bug?

Reply #20
I can't share the file by law.

You'll have to find the bug yourself then.  First, stop using audacity.  Then, decode the file to raw PCM and verify that the error is still present when using the official flac decoder.  If it isn't, you know the problem is in audacity and can seek help from them. 

Re: FLAC bug?

Reply #21
I used Audacity only for:
- re-saving the original WAV in the hope to fix the problem. But it didn't help at all.
- converting WAV to raw data. And that was for the checksum generation only.

Audacity isn't involved into the errorous FLAC conversion itself and I already used the official FLAC codec (the "flac" command). See my original posting. I started using Audacity _after_ I noticed the click sound in the encoded FLAC file.

I converted the source file to FLAC using the official codec. I decoded it with the same tool and the decoded WAV isn't the same as the original one (one sample is different).

I already fixed it for myself by going back from FLAC 1.3.2 to FLAC 1.3.1. I'm still anserwing here because some of you seem still interested in that issue.  ;)

Re: FLAC bug?

Reply #22
So i've found the file he has.
Followed the steps, produces no difference and after decoding the resulting wav has the same sha256. So my guess is that the flac binary has a compile bug.
Although, i'm on windows so maybe that has something to do with it. I tried finding a 1.3.2 deb, but i can't set it up fast right now, so i can't test on linux.

I can upload the file somewhere, but how do i go about tos#9 in this case? He said if he cuts out a sample with the click, it's not reproducable.

Or if you want to look for it yourself, it's from a "special" computer bild edition of the game, image size 641mb.

Re: FLAC bug?

Reply #23
I used Audacity only for:
- re-saving the original WAV in the hope to fix the problem. But it didn't help at all.
- converting WAV to raw data. And that was for the checksum generation only.

Yeah, this is what I was referring to.  Decode the FLAC file and WAV file to raw PCM, and then check that the samples are actually different so you can rule out audacity and the WAV header.  It wasn't clear to me if you'd already done that. 

 

Re: FLAC bug?

Reply #24
I wonder ... should the OP try a memory test?


Edit:
Franky666 : what happens if you take your 1.3.1-encoded FLAC, decode it (two options: with 1.3.1 or 1.3.2) - and then try to encode that .wav using 1.3.2?

 
SimplePortal 1.0.0 RC1 © 2008-2018