When I try to play FLAC files over my network using Winamp 5.0, Apollo (latest version), or QCD with the FLAC plug-in I get the following error message:

________________________________________________________
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

This dll works fine for me
http://support.xmplay.com/Plugins_input.html
(installer wants to find xmplay.exe -- a dummy might suffice -- I just copied to winmp\plugins.) I had the exact same error with the "official" FLAC one.
FLAC code needs more care and maintenance than it's been getting.

Didn't help unfortunately. That dll seems to actually be an earlier version of the FLAC plug-in dll... it doesn't support the metadata properly (no song name listed in the winamp title bar) and the error message I got this time was the same but lacked the final clarification line:

"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 guess you've tried X-Fixer's Winamp Plugin?

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

I have seen this at a friend's. He had broken hardware, but computer worked perfectly for everything else. There is a simple test you can perform.

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.

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

SSHD:

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

Addendum:

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

makes sense, I'll put in the TODO list.

Josh

Cool. Thanks a bunch man, 'preciate the posts and the help.

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

Just a quick follow-up on my previous post. I found the following in the troubleshooting section of the Squeezebox's FAQ. While the topic is specific to AAC, the comments provided about "streaming" (for lack of a better word) audio over a wireless link seem applicable for FLAC as well. 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.




-rt

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

Interesting. I guess that would make the FAQ comments for the Squeezebox equally applicable for FLAC "streaming" over a WLAN. On a sidenote, wouldn't that mean AAC is horribly inefficient? I mean FLAC is much "denser" than AAC to my amateur eye.

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

I guess AAC would only be inefficient compared to FLAC from a bandwidth/quality perspective. It's certainly going to be more efficient in other areas like disk space usage. Note that the Squeezebox developers are interested in adding FLAC decoding in the Squeezebox hardware, which would vastly reduce the bandwidth requirement.

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

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

How would I go about replacing the seektable on a "sample" file?

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

I tried to run some checks on the decoded WAV file from the CMD line (windows) using metaflac (can't run it directly for some reason) but had difficulty setting up the parameters (not much of a command line converter guy I'm afraid). I'll give it a shot later when I have some free time to play around (so many damned commands and options to input... ugh).

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

Okay so I figured out how to do the list command on flac files using metaflac and got a report on various versions of the the sample file I've been using.

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 Files\FLAC>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 Files\FLAC>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 Files\FLAC>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)

I don't think the seek table is what's causing your problem; the seek table's never used unless you try to seek (i.e. move the slider around in winamp).

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

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.

sounds like it could be a buffering problem - sorry for throwing a red herring in there.

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

It is a pity that the flac plugins don't get updated regularily. Now with the new Winamp5 SDK out, it should be easier to support more advanced winamp features.

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.

For a really dirty solution couldn't you just write a batch file (windows here) to do a recursive run through and just apply the following to each directory?

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

Josh, maybe you can answer my question?

Is X-FIXER still willing to maintain his flac creations?
Or isn't he contributing anymore?

haven't heard from him lately so I don't know...

I'll send him email pointing to this topic.

Josh

TNX, I was just wondering because his HP hasn't been updated for such a long time.

Did you scuceed in contacting X-Fixer, Josh?

I think that the winampGetExtendedFileInfo() function would be an imortant feature that should be included (you can't use the ML without it properly for flac files)

yeah, he said he hasn't had time to maintain the plugin lately.

Josh

Sorry for jumping in here but I have a very similar problem with my collection.

I committed myself a few months back to getting all my CDs on to my pc for a music jukebox in the living room. I've bought a new pc for the job, a CD drive for ripping, a decent sound card, an amp and a wireless keyboard/mouse - I even bought a nice LCD flat panel....

For a few weeks, I ripped my collection using EAC and then FLAC’d them over many nights. Eventually I finished. But, I was using an external HDD and I was always getting problems ("delayed write" errors). This translated into lots of faulty FLACs. So, I tried to put the drive in my PC and for some reason, thought I'd resize the 300gb drive (okay, I now know a 300gb partition wasn't my best plan to begin with but I thought it would work externally) so I could put an OS on a separate partition. Well, the resize failed and this resulted in 70% of my rips becoming unplayable .

So, like a trooper, I managed to install XP on the drive (still 300gb) which seemed to fix the problems with the partition resize and then re-ripped my files. All seemed good.

However, whilst playing my collection using Winamp 5.02, I got a decode error (sometimes a seek error). Thinking it was a one off file, I ran a test on every FLAC file. It drew up a list of about 50 files from a variety of albums wit decode and seek errors. Not happy, I ran the test again and only two files failed. I ran it again and only one. The one that kept failing always fails, but some of the others, not even the ones of my original error list, will work and play sometimes and not others. They'll fail in Winamp and fail after a "FLAC -t FILE.flac". A minute later, it'll work in Winamp and work using “FLAC –t”.

So, it seems, sometimes files will play and sometimes fail. With no consistency (apart from the one file which always fails). I've tried testing files using "FLAC -t" repeatedly over about 30mins. I did this under added stress (HDD searches, Winamp visualisations etc) and it tested out fine. So, I don't think it's memory or CPU related. Could it be HDD related? I don't know how much damage was done after I tried to resize. I don't get any other errors on the machine. XP loads fine.

Any suggestions? I'm at a loss. How can I rule out the memory, CPU and HDD for sure? There's about 200GB of FLACs all together - too much for me to back up on another drive. I'll need another 200-300GB drive for a backup. And, if the problem is with the HDD, how can I be sure my backup will be okay? I was planning on RAR'ing every FLAC, immediately after a successful "FLAC -t", with a recovery record of 3%, then copying the RARs to my backup drive. I could then reformat and partition my original drive more sensibly, and copy the stuff back and unRAR them. Does this make sense? Is there another way?

All my FLACs are compressed with maximum compression (best) and my machine is a Shuttle XPC with a Celeron 2.4ghz CPU - 256MB RAM and 300gb HDD formatted with NTFS running XP SP-1.

Please help, I can't bear to rip my collection AGAIN !

Many thanks

Gareth

highly unlikely that the problem is with flac. sounds like your drive and/or data is hosed.

maybe there are some recovery tools that can get something out before increasing the damage.

if the filesystem allocation tables are messed up, continuing to write to the drive may corrupt even more data.

Josh

Thanks, Josh. I guess I'll continue with the backup plan minus creating the RARs, if doing so is likely to cause more harm than good.

I'm not having much luck with this! Now my wireless keyboard is playing up