SBE fix gives different result with shntool & flac front-end?

[4candles]

Originally Posted by uhclem

I've never heard this before. I'm skeptical. Even if it were true I seriously doubt that FLAC is randomly putting in a few non-zero samples to deal with it. There is no mention of this in the FLAC documentation. I think 4candles indentification of a bug in the source code sounds like the best explanation. Good catch, 4candle & pig. We need to put something about this in the FAQ and in the etree wiki.

I think this bug (assuming I'm right) has been in flac for a long time, so there's probably no urgent rush to document it without confirming the bug with the flac developers.

I've emailed the FLAC developers mailing list about it and I'll report back here when I get a reply.

[fatoldpig]

thanks for looking into this. hopefully it's a bug with flac front-end and they'll fix it soon.

[Five]

Originally Posted by uhclem

I've never heard this before. I'm skeptical. Even if it were true I seriously doubt that FLAC is randomly putting in a few non-zero samples to deal with it. There is no mention of this in the FLAC documentation. I think 4candles indentification of a bug in the source code sounds like the best explanation. Good catch, 4candle & pig. We need to put something about this in the FAQ and in the etree wiki.

after searching for a bit I can't find any reference to this anywhere online & I can't remember where I heard it. So it looks to me like this is a minor bug with FLAC frontend like everybody's been saying... sorry guys for putting forward this questionable information without doing my research first!

[4candles]

Originally Posted by fatoldpig

thanks for looking into this. hopefully it's a bug with flac front-end and they'll fix it soon.

It's nothing to do with flac front-end, it's a bug in the "flac" program itself (i.e. flac.exe for Windows users).

I've had no reply yet, but my bug report can be found here:

http://lists.xiph.org/pipermail/flac...July/date.html

[skyofcrack]

In the meantime, just to be safe, should we untick the box in FLAC Frontend for 'align on sector boundaries,' if I'm understanding this conversation correctly?

soc

[feralicious]

How come noone has mentioned that simply going from flac > wav > flac (align on sector boundaries) isn't the proper way to fix SBEs? I distincly remember being schooled on that in a thread a while back. Doesn't that cause it to not shift the data from track to track but rather pad each track individually thereby adding silence between tracks? It should go flac > wav > fix SBEs > flac, no?

Or am I completely mad?

[4candles]

Originally Posted by feralicious

How come noone has mentioned that simply going from flac > wav > flac (align on sector boundaries) isn't the proper way to fix SBEs? I distincly remember being schooled on that in a thread a while back. Doesn't that cause it to not shift the data from track to track but rather pad each track individually thereby adding silence between tracks? It should go flac > wav > fix SBEs > flac, no?

Or am I completely mad?

Taking the simple example of three files, there are two ways to convert them to flac. Firstly, by running flac.exe three times:

flac -8 file1.wav
flac -8 file2.wav
flac -8 file3.wav

or the alternative is to just run flac.exe once:

flac -8 file1.wav file2.wav file3.wav

The "--sector-align" option only makes sense when you are using the second method. Using the first method (running flac separately for each file) will do as you describe, and simply pad each track with silence. The second method will move partial sectors from the end of one track to the start of the following track - exactly the same as shntool does (by default).

I believe that early versions of FLAC Front-end used the earlier method, and hence the sector-align facility in FLAC Front-end was useless, but I believe that recent versions of FLAC Front-end do the right thing.

And to answer the previous question, yes, I wouldn't use the sector-align option in FLAC any more - at least until a bug-fixed release is made.

I still haven't heard anything back from my bug report, but it's only been a little more than 24 hours.

[skyofcrack]

I've always used shntool to fix my sbe's and I'll definitely turn off that function until I hear back about the bug.

Thanks for the heads up.

soc

[Beleaguered]

Originally Posted by 4candles

It's nothing to do with flac front-end, it's a bug in the "flac" program itself (i.e. flac.exe for Windows users).

I've had no reply yet, but my bug report can be found here:

http://lists.xiph.org/pipermail/flac...July/date.html

You might also want to document your bug on the bug tracker:
http://sourceforge.net/tracker/?grou...78&atid=113478

[4candles]

Originally Posted by Beleaguered

You might also want to document your bug on the bug tracker:
http://sourceforge.net/tracker/?grou...78&atid=113478

You're right - that's the correct way to report a FLAC bug. I've added it here:

http://sourceforge.net/tracker/index...78&atid=113478

Thanks.

[fatoldpig]

for now i'll use, shntool fix -o flac *.flac to fix sbe.

[ssamadhi97]

cute, flac accidentally pads with samples from "earlier"



padded data (196 samples) is identical with the highlighted selection

[Ted]

I pretty sure that's what 4candles found out when he earlier posted about it not clearing the buffer before padding. I think he discovered that it cleared only the first half of the buffer.

[Five]

and it looks like the bug was missed because the 2nd half of the buffer will often be zero samples anyways.

[4candles]

Originally Posted by ssamadhi97

cute, flac accidentally pads with samples from "earlier"



padded data (196 samples) is identical with the highlighted selection

Nice picture - it summarises the bug nicely, which as you say is that flac only half-clears the buffer, leaving data from earlier in the input file in the second half.

I'm surprised by the lack of response to my bug report - maybe Josh is on vacation...