Flac file decoder seekable stream decoder error

________________________________________________________
FLAC Plug-in Error

Error while processing frame (FLAC__FILE_DECODER_SEEKABLE_STREAM_DECODER_ERROR)
The error is caused by corrupted file or hardware malfunction
________________________________________________________

Both systems involved are Windows XP Pro computers.  One of teh machines is connected wirelessly via an Orinoco Gold adapter, the other is connected via a 10/100 NIC.  All my hardware works fine in general, I just seem to have this problem streaming FLAC files.  I should note that file transfers between teh machine also sometimes have problems, and can be very slow.

Is this a connection problem?  Anyone else running a wireless network with XP and have trouble streaming?

Thanks in advance for any help.

-rt

«The error is caused by corrupted file or hardware malfunction»

I just get the code for the error.

Thanks for the 411.  For some reason I think FLAC is choking on the bandwidth of my wireless connection.  I don’t really have this issue when I’m wired, and teh only difference (since my connection is pretty stable) is the total throughput available with 802.11b (about 6mbps max).

Just seems really odd that streaming FLAC would be SO demanding… I mean doesn’t it have a way of regulating itself?  I would think at the very least one of the players Ive used, like Winamp, would be better able to «iron out» streaming problems…

-rt

I think X-Fixer made the new one as well, but I can’t remember where I got it (I’ve downloaded so many dlls and plug-ins at this point its all a blur).  It shows the version number in the Winamp plug-in manager.

Thanks for the link.

-rt

There’s actually a newer version of the plug-in post the one you linked from X-Fixer.  The one you linked is 1.0beta6, and the newer version is 1.0beta7.  I was originally running 1.0beta7, tried the XMPlay version mentioned previously, and reverted back to 1.0beta7.

I think X-Fixer made the new one as well, but I can’t remember where I got it (I’ve downloaded so many dlls and plug-ins at this point its all a blur).  It shows the version number in the Winamp plug-in manager.

Thanks for the link.

-rt

http://x-fixer.narod.ru/download/in_flac.zip

Get flac.exe and create this little test script  test.cmd

:test
flac -t mylargefile.flac
goto test

Then let it run for at least 15 minutes (will use 100% CPU and increase the temperature inside the computer). If it sometimes fails and sometime succeeds, you have a heat/hardware problem.

You should test your RAM as well.

For some reason I think FLAC is choking on the bandwidth of my wireless connection.  I don’t really have this issue when I’m wired, and teh only difference (since my connection is pretty stable) is the total throughput available with 802.11b (about 6mbps max).

Just seems really odd that streaming FLAC would be SO demanding… I mean doesn’t it have a way of regulating itself?  I would think at the very least one of the players Ive used, like Winamp, would be better able to «iron out» streaming problems…

first, it doesn’t sound like what you’re doing is streaming, it sounds like you’re playing files over a network.  they’re two different things.

the first usually refers to a client and server communicating using a protocol like RTP which is designed for real-time communication over possibly unreliable networks.

the second is making remote files appear local through some protocol like NFS or samba, then playing those files with winamp as if they were local.  these protocols are not designed for timely uninterupted delivery of data and can’t cope with interruptions.

next, you say you’re playing over a wireless connection with a max throughput of 6mbps.  those are marketing mpbs.  have you measured your actual average throughput to see what you’re really getting?  a FLAC from CD audio can have a bitrate up to .75 the CD rate in some cases, or around 1mpbs.  if you don’t get that average rate (plus who knows how much extra for overhead like samba/nfs and whatever else is using the network) you will have problems.  also I don’t think winamp does enough buffering in file based playback to handle long bandwidth drops.  who knows, maybe your file-sharing protocol floods the channel every so often and that could be causing the dropouts.

Josh

My hardware is fine.  I run burn tests and hardware checks regularly, and everything has checked out without a hitch.  If anything I would presume a throughput problem before a hardware problem, especially since I don’t see the problem on ethernet.

jcoalson:

Yes, I am «streaming» the music over my WLAN, so I guess my use of the word was mistaken.  I assumed that any case of calling a media file from one client to a «server» (whether LAN, WLAN, WAN, or Internet) was streaming, but I guess the name has more technical parameters than that.

I’ve tested my connection a bunch of different ways, and in just about every test it pushes above 5mbps.  The marketing speeds are 8-11mbps, and I’ve never had any problem getting 6mpbs as long as I’m within good range of the AP I’mn connecting to.  This may have something to do with the fact that I have an excellent adapter (Orinoco Gold), I don’t know.

Point is that at the very least I get 2.5mbps from my client to a web server in southern california, and since I’m in the northeast that’s a pretty good speed.  Even if my test indicating I get 5mbps+ locally was wrong the 2.5mbps speeds I get to my server DEFINITELY isn’t wrong.

Does this mean that I need more throughput than that to play FLAC files over my network?  Isn’t that kind of extereme since I can play video over the web with less?  From your later comments it seems like my instinct about this being a buffering problem more than a connection of play problem could be accurate, but as far as I can tell none of these programs allow you to increase the buffer size…?

Thanks for all the posts and responses, I appreciate it.

-rt

I was just looking at the controls afforded other codec plug-ins regarding buffering, pre-caching, and streaming and was wondering if maybe the same functionality couldn’t be incorporated into the FLAC plug-in?  I don’t know who built or compiled it, but it seems that given the large size of FLAC files the ability to specify a large buffer when playing FLAC files is a crucial feature that is noticeably absent from the plug-ins configuration screen.

My FLAC files generally come in at between 700kbps and 950kbps or so, with some variance outside that range, but from what I can see the buffer used in Winamp et al is never greater than 128k or so, and usually closer to 64.  At that rate even a small bump or hiccup while loading a FLAC file is enough to cause the player to outpace the buffer and suffer a delay.

Anyway, just a thought.

-rt

Josh

On a further note, this whole experience has actually gotten me interested in how it would even be feasible to stream or transmit FLAC over a wireless (802.11b) network in any capacity.

I know that the Squeezebox supports FLAC and has an 802.11b adapter, so I wonder if they didn’t come up with a solution to this throughput problem for the device.  Maybe a large cache or buffer?  Maybe they didn’t solve it and wireless on the Squeezebox is a nightmare when playing FLAC and other large files?

I’ll have to look into it and see… thanks again for the help and responses.

best,
-rt

Taken from squeezebox FAQ:
I’m trying to play AAC files on my Squeezebox over a wireless network and the audio sometimes pauses or breaks up.
This may be caused by insufficient speed in your wireless network. Here’s why:

By default SlimServer will uncompress AAC files on the server side and send the uncompressed audio to the Squeezebox. Uncompressed audio at 16-bit resolution with 44.1kHz sampling rate, stereo, ends up around 1600 kilobits per second— as opposed to the compressed AAC bitrate which is typically around 128 kilobits per second.

When operating wirelessly on both ends of the network (i.e. wireless from computer -> base station, and base station -> Squeezebox), that data rate doubles. So you’re trying to seend more than 3 megabits per second over 802.11b.

In theory, this should not be a problem, but it can be in the real world. 802.11b has an absolute maximum data rate of 11 megabits per second. Typical throughput to a given wireless client on an 802.11b network rarely ever exceeds 3-5 megabits per second.

For better AAC performance over wireless, you can reconfigure the server to convert the AAC audio to a very high quality MP3 format. To do this, you’ll need to install an MP3 encoder called LAME.

Mac Users:

Download the iTunes-LAME plugin, and drag the iTunes-LAME program from the top left to the bottom right alias (following the arrow).
Then you’ll need to tell SlimServer to use LAME to convert your AAC files to MP3. To install a settings file that does this, download this disk image file, open the drag the new convert.conf update into the red alias called «Drag the convert.conf file here».

-rt

… Maybe even more so give how much more demanding FLAC files are than AAC… the bit rate on my FLAC files averages like 850, which over 6x the 128kbps AAC they discuss.

Just to clarify: both AAC and FLAC are equally demanding on your wireless Squeezebox setup because they are both decoded to raw PCM format before being sent over the wire.

—jth

Regardless, very annoying since my network is composed of 802.11b equipment presently.  I guess I could thread a cat5e cable from the router to the stereos position, but I was hoping to be able to stream FLAC to an old laptop by my stereo via wireless.

BTW, since you seem to know something about the subject, does 802.11g provide enough throughput to get around these problems?  Figure 802.11g hits around 15-20mbps max real world, so it isn’t a HUGE gain and nowhere near what ethernet pprovides, but maybe its just enough…

Too bad the squeezebox doesn’t use 802.11g 

-rt

You need a strong signal to stream FLAC (essentially WAV in this situation) on 802.11b. I am able to do it with about 60% signal strength on the Squeezebox. A lot of people have trouble.

802.11g would probably help. You can buy a 802.11g bridge to use with the wired-only Squeezebox.

By the way: the Squeezebox has 2 MB of buffer.

—jth

________________________________________________________
FLAC Plug-in Error

Error while processing frame (FLAC__FILE_DECODER_SEEKABLE_STREAM_DECODER_ERROR)
The error is caused by corrupted file or hardware malfunction
________________________________________________________

I may be off target here, so please don’t shoot me down but…

have you seen the thread I started on flac seeking problems?
Flac seeking problems

I had what appears to be similar errors to the ones you are getting, and the problem could be due to the seektable in the flac file.
Do you always get the error with a particluar file, or is it random. If it’s with a particular file or files, try replacing the seektable in those files with one created by metaflac and see if that solves your problem. 1 second seekpoints worked for me.

— Audio Spyder

I’m not that familiar with how FLAC files are encoded or how to get in and mess around with them, but I’d be interested in testing it to make sure the seek table on my files checks out okay.  I tested a few with flac front-end’s test feature and they checked out alright, but I don’t think that test would catch problems with the seektable (though I don’t really know).

As for my specific problem: whenever I play FLAC files over a wireless link they have a tendency to crap out.  Sometimes this is a pause with a brief return to playing like 30 seconds later and then another pause, sometimes its an outright «error» as stated before, and sometimes the file just won’t play at all to begin with.

As I said earlier I think my problem is really a question of bandwidth and throughput since the issue only seems to surface on lower throttled connections to the server.  I think I see the seekable stream error when the decoder suffocates due to a lack of input but a demand for output from the player (winamp et al)… like the decoder has a brain fart since the player is asking for data that isn’t being delivered and isn’t available.  However, maybe a problem witgh the seek table would provide a further complication that undermines my ability to play the files.

If you could let me know how to test the seek table or rebuild it I’d appreciate it.

Thanks,
rt

However, I did come across something interesting.  I encoded all my FLAC files directly from the rip using Easy CD-DA Extractor 6.  [Yes, I’m aware of Jukka’s *cough* interesting versioning policy and questionable SPAM practices.  However, author aside I find the program very easy to use and like the fact that it allows me to directly encode FLAC files from teh CD (as opposed to EAC’s CD-WAV-FLAC format).  The GUI interface is just easier for me.]

Anyway, what I found is that the files I encoded with ECDDA 6.x are larger than the same file created using FLAC Front-End/Flac.exe.  Basically if I decode the existing FLAC file to WAV and reencode with both FLAC.exe and ECDDA 6.5.9 (latest version) the ECDDA copy is noticeable larger.

An example would be «Dust Bowl» from 10,000 Maniacs Blind Man’s Zoo album (it was at the top of the jukebox directory).  The existing FLAC file comes in at 21.5mb encoded at level 8 FLAC.  If I decode and reencode using Flac.exe the file size of the resulting FLAC file is 20.8mb, while if I decode and reencode with ECDDA it again comes out to 21.5 (performed to insure the earlier ECDDA version I used wasn’t the problem).  This is with all the same settings, file data input the same, etc.

700k seems like a noticeable difference to me.  I suppose ECDDA could just be inefficient when compared with Flac.exe’s encoding, or there could be something else I don’t see.  However, shouldn’t the same file encoded to level 8 FLAC using two different methods be closer to the same size than 700k?  Is this an indiciation of something wrong with ECDDA’s encoding?  With Flac.exe’s encoding?

Looking forward to any thoughts.

Thanks,
rt

The first thing I noticed is that none of the files I encoded with ECDDA actually HAVE a seektable!  I’m not sure what this means or how significant it is, but given that it is apparently important for seeking (logical assumption I’m trying) maybe this is an important discovery?  In light of this the fact that my ECDDA encoded files are LARGER is even more confusing; there is a great deal more metadata in the file encoded with flac.exe, yet its 700k smaller…?

On a sidenote, assuming I need a seektable for all my files is there a way to batch edit 88gb worth of FLAC files automatically? 

For reference, below are the list results I got running metaflac against various versions of the file.  The first is the originally encoded FLAC file from my archive (encoded with ECDDA).  The second is a decode/reencode using flac.exe.  The third is a decode/reencode using ECDDA.  Note that the only difference between the two ECDDA versions (both of which lack a seektable) is the field «length:» in METADADA #1.  For the original its 211, for the reencode its 212.

I’d appreciate any thoughts ya’ll have on this post.

Thanks,
rt

p.s.  sorry for the number and length of posts, kind of rambling along through this analysis 

C:Program FilesFLAC>metaflac —list DustBowl_original.flac
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minumum blocksize: 1152 samples
  maximum blocksize: 1152 samples
  minimum framesize: 499 bytes
  maximum framesize: 3202 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 11140836
  MD5 signature: b9f374ad94e4dd5aef72b8cf514eb8d7
METADATA block #1
  type: 4 (VORBIS_COMMENT)
  is last: true
  length: 212
  vendor string: reference libFLAC 1.1.0 20030126
  comments: 7
    comment[0]: TITLE=Dust Bowl
    comment[1]: TRACKNUMBER=8
    comment[2]: ARTIST=10,000 Maniacs
    comment[3]: ALBUM=Blind Man’s Zoo
    comment[4]: DATE=1989
    comment[5]: GENRE=Folk
    comment[6]: ENCODER=Easy CD-DA Extractor (http://www.poikosoft.com)

C:Program FilesFLAC>metaflac —list Dustbowl_flacexe.flac
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minumum blocksize: 4608 samples
  maximum blocksize: 4608 samples
  minimum framesize: 1955 bytes
  maximum framesize: 12392 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 11140836
  MD5 signature: b9f374ad94e4dd5aef72b8cf514eb8d7
METADATA block #1
  type: 3 (SEEKTABLE)
  is last: false
  length: 450
  seek points: 25
    point 0: sample_number=0, stream_offset=0, frame_samples=0
    point 1: sample_number=442368, stream_offset=0, frame_samples=696466
    point 2: sample_number=889344, stream_offset=0, frame_samples=1521283
    point 3: sample_number=1336320, stream_offset=0, frame_samples=2371862
    point 4: sample_number=1778688, stream_offset=0, frame_samples=3336073
    point 5: sample_number=2225664, stream_offset=0, frame_samples=4239085
    point 6: sample_number=2672640, stream_offset=0, frame_samples=5147528
    point 7: sample_number=3115008, stream_offset=0, frame_samples=5980445
    point 8: sample_number=3561984, stream_offset=0, frame_samples=6846865
    point 9: sample_number=4008960, stream_offset=0, frame_samples=7749251
    point 10: sample_number=4455936, stream_offset=0, frame_samples=8711213
    point 11: sample_number=4898304, stream_offset=0, frame_samples=9607825
    point 12: sample_number=5345280, stream_offset=0, frame_samples=10497351
    point 13: sample_number=5792256, stream_offset=0, frame_samples=11423757
    point 14: sample_number=6234624, stream_offset=0, frame_samples=12389569
    point 15: sample_number=6681600, stream_offset=0, frame_samples=13257546
    point 16: sample_number=7128576, stream_offset=0, frame_samples=14084905
    point 17: sample_number=7575552, stream_offset=0, frame_samples=14976293
    point 18: sample_number=8017920, stream_offset=0, frame_samples=15911096
    point 19: sample_number=8464896, stream_offset=0, frame_samples=16862879
    point 20: sample_number=8911872, stream_offset=0, frame_samples=17740812
    point 21: sample_number=9354240, stream_offset=0, frame_samples=18621421
    point 22: sample_number=9801216, stream_offset=0, frame_samples=19609638
    point 23: sample_number=10248192, stream_offset=0, frame_samples=20619135
    point 24: sample_number=10695168, stream_offset=0, frame_samples=21418566
METADATA block #2
  type: 4 (VORBIS_COMMENT)
  is last: false
  length: 135
  vendor string: reference libFLAC 1.1.0 20030126
  comments: 5
    comment[0]: TITLE=Dust Bowl
    comment[1]: ARTIST=10,000 Maniacs
    comment[2]: ALBUM=Blind Man’s Zoo
    comment[3]: DATE=1989
    comment[4]: GENRE=Folk
METADATA block #3
  type: 1 (PADDING)
  is last: true
  length: 4001

C:Program FilesFLAC>metaflac —list DustBowl_ecdda.flac
METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minumum blocksize: 1152 samples
  maximum blocksize: 1152 samples
  minimum framesize: 499 bytes
  maximum framesize: 3202 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 16
  total samples: 11140836
  MD5 signature: b9f374ad94e4dd5aef72b8cf514eb8d7
METADATA block #1
  type: 4 (VORBIS_COMMENT)
  is last: true
  length: 211
  vendor string: reference libFLAC 1.1.0 20030126
  comments: 7
    comment[0]: TITLE=Dust Bowl
    comment[1]: TRACKNUMBER=8
    comment[2]: ARTIST=10,000 Maniacs
    comment[3]: ALBUM=Blind Man’s Zoo
    comment[4]: DATE=1989
    comment[5]: GENRE=Folk
    comment[6]: ENCODER=Easy CD-DA Extractor (http://www.poikosoft.com)

you could use ‘metaflac —list file.flac’ to see the metadata but I haven’t verified yet whether that other windows+seektable bug is in the file itself or in the code that reads the seektable.

small disparity is sizes could be caused by several things.  e.g. the other encoder may have been built with SSE optimizations enabled which if I remember right yields slightly larger files.

Josh

Thanks for the reply.  That’s pretty much what I figured from the name of the rror… I wasn’t seeking when it would cramp up initially, so that probably wasn’t the source of my underlying problem.  In retrospect its possible I only saw that error AFTER I tried to seek while it was frozen or «not playing.»  In that case maybe I was seeing the seek error because I was attempting to seek on no data (buffer underun), and the decoder was returning the seek error as a response to having no data to seek to?

As for the seek table, the wierd thing is that I can seek just fine using all three versions of the file; the original ECDDA encoded version, the FLAC.exe version (the only one with a seek table), and the reencoded ECDDA version.  I have them all open in Winamp right now and they seem to hop around with the slider exactly the same.

That being the case, what would the effect of including or excluding a seek table in teh files be?  Stability in terms of seeking and playback?  Do I need to or would I want to add a seek table to all my files?

I’m a regular on the Karma forums as well (I now know where they got the new forum software…  ) and have always recommended ECDDA as an easy way for people to use Flac with a simpel GUI interface (in the face of adverse EAC reactions).  However, if it’s leaving out data that’s both useful and necessary I’ll have to rethink that entirely.

Thanks again for all the input.

Best,
rt

UPDATE:
Uncovered the following online using google in a manual on stanford.edu.  It appears to answer my question about why I can still seek even though the ECDDA files don’t have seek tables:

«You may use many -S options; the  resultingSEEKTABLE  will  be  the  unique-ified union of all such values. With no -S options, flac defaults to ‘-S 10s'»»

However, I’m still interested in knowing if there is an advantage to specifying a seek table or letting flac specify its own seek table (default 10s).  I’m also interested in knowing whether, irregardless of a bug per the other thread linked previously, there is an advantage to having smaller seek points than 10s.

As for the seektable, I encode a single flac per album, and therefore to change tracks requries a seek. I’ve found that by having 1second seekpoints (instead of the default), I don’t get the decode error at all. Before, some files would cause a problem, while others were ok. Now all play back fine.

To batch add a seektable, I couldn’t find an easy way, so I ended up using excel to create a .bat file which I then let run over a couple of days. It’s long winded, but if you are interested, I can let you know the details — it doesn’t require much excel knowledge, but is not as easy as clicking on a few buttons.
I’m sure other people will have a much more sensible solution.

-Audio Spyder

Does X-FIXER contribute to the FLAC project anymore or did he leave?
His HP hasn’t been aupdated for more than a year now.

metaflac —add-seekpoint-1s *.flac

I don’t do much (read any) work with windows batch files, so off-hand I don’t really know what the necessary commands would be.  However, I have to imagine that even with the limited commands available for windows batch files you could write a program that would just open metaflac, do a recursive search from a top level directory, run the add seekpoint option on each file it encounters, and close when it reaches the directory end or returns no .flac files.

Possible? I would think it would be easier than using excel fo the task… YEEEEECH, don’t like excel much to begin with, and using it for a batch application on 88gb of my «the precioussssss» isn’t at the top of my list.

Interested in any thoughts anyone has.  Of course I’d also happily except a front-end for metaflac that provide the ability to run recursive options on files… anyone? 

-rt