Help - Search - Members - Calendar
Full Version: FLAC decoding error
Hydrogenaudio Forums > Lossless Audio Compression > FLAC
sTisTi
Hi,
I just embarked on a big project to rip all my CDs to FLAC (I already have high quality lossy files, but lossless is lossless wink.gif )
I decided to go with Plextools Pro as it rips very fast with my Plextor 716A and is supposedly as secure as EAC. Plus, it allows direct ripping to FLAC (with automatic tagging). However, I just tested some of the files I ripped in the first session yesterday and all of them give me this error when testing them through the FLAC frontend:
CODE
flac 1.1.2, Copyright (C) 2000,2001,2002,2003,2004,2005  Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

01 - Sivuca, accordion - Noites Cariocas.flac: *** Got error code 0:FLAC__STREAM
_DECODER_ERROR_STATUS_LOST_SYNC


01 - Sivuca, accordion - Noites Cariocas.flac: ERROR while decoding data
                                              state = FLAC__STREAM_DECODER_READ
_FRAME

-------------------------------------------------------------------------------

Drücken Sie eine beliebige Taste . . .

It always happens right at the beginning of the files. I suspected the tagging of Plextools; But if i manually remove the tags with MP3Tag, the problem persists. Only if I let Plextools extract the files without entering any information or freedb-query, Plextools seemingly does not add a tag, and then the files work. If I then add tags with MP3Tag, everything still works. So something must be screwed up when Plextools adds the FLAC tags. Strangely, although the FLAC frontend gives error warnings when testing or decoding the files, they play without problems in WinAMP.
Has anyone experienced this issue? My guess is that Plextools is buggy and somehow corrupts the FLAC file when the tag is added, maybe it simply overwrites the beginning of the file with the tag? Interestingly, when I force FLAC to decode the file despite the errors, the resulting .wav file also gives errors when I try to encode it back to .flac - FLAC complains that the .wav file is unexpectedly shorter than it thought. Strange...
Involarius
Something I experienced yesterday which may be a lead...

I downloaded CDex 1.60 from RareWares yesterday--it's an unofficial modified version, a beta, with a few additional features (in relation to the official, stable 1.51), among them ripping directly from CD audio to FLAC.

I tested it. I ripped one track to FLAC--one that I've already got in a FLAC archive (which I'd made by ripping from CDex 1.51 to WAV and then to FLAC with the FLAC frontend). I compared the two files. The FLAC from CDex 1.60 was quite larger than the older one, though I used the same compression setting, -5, for both. I dragged the new FLAC into Winamp and played it. OK. But then I double-clicked to edit the file's metadata, and lo and behold, Winamp froze and I had to nuke it.

So I have a hunch we've both been up against the same buggy FLAC Encoder DLL. Of course, I'm not sure. But it seems bloody like it.
jcoalson
can you upload a sample file for testing?

Josh
sTisTi
QUOTE(jcoalson @ Oct 11 2005, 04:26 PM)
can you upload a sample file for testing?

Josh
*


Test file uploaded here:
http://www.hydrogenaudio.org/forums/index....showtopic=37827
jcoalson
I see the problem... the length of the VORBIS_COMMENT metadata block is wrong, it is one byte greater than it should be. so when the decoder eats the comment block it also eats the first byte of the first frame and loses sync.

it will take some investigation to see if this is a libFLAC problem or plextools in the way it writes tags.

my first hunch is that they may not be handling the tag value encoding right... the tags in the file are ascii, but since it looks like spanish... did you tag it with any non-ascii characters? (like with accents?) then maybe plextools converted them to ascii but did not correct the byte count.

Josh

btw if I fix the VORBIS_COMMENT length in the file, it is perfectly decodable.
sTisTi
QUOTE(jcoalson @ Oct 12 2005, 10:03 AM)
my first hunch is that they may not be handling the tag value encoding right... the tags in the file are ascii, but since it looks like spanish... did you tag it with any non-ascii characters? (like with accents?)  then maybe plextools converted them to ascii but did not correct the byte count.
btw if I fix the VORBIS_COMMENT length in the file, it is perfectly decodable.
*


It happened with all files, even if no accents or other symbols were used. In the sample I uploaded, there were only ascii characters AFAIK. But regardless of this, Plextools also seems to screw up non-ascii characters in the tags if they actually do occur. Strangely, with some programs (like dbpowerAMPs 'popup info' in the Explorer), the non-ascii characters are displayed correctly, while with other programs (like MP3Tag or the WinAmp flac plugin) they are converted to characters like '?'
I am going to upload another sample that makes use of non-ascii characters so you can check it.
Emanuel
What version of Plextools Pro are you using? This is/was a known problem that is fixed since version 2.19a

Hope that helps.
sTisTi
QUOTE(Emanuel @ Oct 12 2005, 11:21 AM)
What version of Plextools Pro are you using? This is/was a known problem that is fixed since version 2.19a

Hope that helps.
*


That thread seems to talk about a different problem; anyway, I'm using Plextools Pro 2.21. I'm still waiting for an answer from Plextor support. I'll post here what they say to this problem.
Triza
If that helps I use Plextools Pro 2.23 and never had this problem.

Triza
Emanuel
QUOTE(sTisTi @ Oct 12 2005, 08:47 PM)
I'm still waiting for an answer from Plextor support. I'll post here what they say to this problem.
*

Please don't expect them to write back - I haven't yet recieved any answer to bug reports and questions.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.