<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV>Harry,</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>You assume that the only way to use FLAC is the way that you are using it, by converting one file format to another. That's not the only way to use FLAC. The most important uses of FLAC are for internet streaming radio or hand-held digital audio players. Both of these prominent uses are not really file based, but are stream based. It makes perfect sense for the core of FLAC to be stream based. It makes the code small and portable to any platform, no matter how limited.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Besides, the API has support for seekable streams and files.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The big issue here is that you actually believe it is possible to support multiple processors and, further, that there would be an advantage to this. Those are both really big assumptions. I don't think anyone else, besides you, believes that it is possible or desirable for the FLAC codec to be multithreaded.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Harry, you've sent 90 to 100 messages to these mailing lists asking about whether FLAC supports every possible feature that a given piece of software or an audio format could have. If you read about a feature someone else, you come here asking when FLAC will support that feature, or why not, without any idea of why it would even be good, or even possible. You don't seem to understand that it is not possible to put every feature into every program, not just because of development resource constraints, but also because certain features are mutually exclusive. Certain features make other features impossible, or at least undesirable. It simply isn't possible to do some of the things you're asking for, and I am actually surprised that you don't understand why they are impossible. You have basically shown a lack of solid understanding of formats, mathematics, programming, and logic.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>There is a popular saying: "The is no such thing as a stupid question." Well, Harry, you're the first person I've experienced who thoroughly challenges that statement.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Brian W.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR><DIV><DIV>On Sep 8, 2007, at 06:02, Harry Sack wrote:</DIV><BR><DIV><SPAN class="gmail_quote">2007/9/8, Josh Coalson <<A href="mailto:xflac@yahoo.com">xflac@yahoo.com</A>>:</SPAN><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> it actually is complicated. the libFLAC api is not suited to a<BR>multithreaded design because the i/o is stream-based, not file-<BR>based. flac(.exe) is the file-based wrapper around libFLAC that<BR>allows it to work on files. the way libFLAC buffers data is also <BR>impossible to parallelize without significantly changing the api.</BLOCKQUOTE><DIV><BR> <BR> why was this approach used? The API design seems to me not very smart because it's not flexible and you're stuck in the future (like now for multiple core support)<BR> I don't see any reason why you wouldn't make it all based on files and not on streams :s It's just a major disavantage in my opinion<BR> </DIV><BR><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">it would take a specialty file-based encoder using an independent<BR>frame encoder to do and even that is not trivial. </BLOCKQUOTE><DIV><BR> <BR> so we can assume that those API changes will never come and the flac encoder will never have multiple core support?<BR> <BR> thx<BR> </DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR></DIV></DIV><BR></BODY></HTML>