<br><br><div><span class="gmail_quote">2007/9/8, Brian Willoughby <<a href="mailto:brianw@sounds.wa.com">brianw@sounds.wa.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;">
<div style=""><div>Harry,</div><div><br></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></blockquote><div><br><br>1) I never said this is the only way to use it: you put those words in my mouth, I never told this to anybody :) <br>I also didn't say the fact that the API is based on streams is bad! I only say it's not a good choice if you want to support multiple threads ...
<br>Please read carefully what I write :)<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;"><div style=""><div>Besides, the API has support for seekable streams and files.
</div><div><br></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></blockquote><div><br><br>2) you really show you have no good knowledge about programming. There are several codecs out there that try to use multiple cores.<br>To give a concrete example: <a href="http://www.lame-mt.com/">
http://www.lame-mt.com/</a><br>Here is the prove there is a HUGE performance boost:<br><br><font size="2">'</font><span style="font-size: 13.5pt;"><font size="2">The
output of this multi-threaded version, based on LAME 3.97 alpha, is 1:1 bit
compatible with the original version and it gains <b><span style="color: red;">~1.16x
speedup</span></b> when Constant Bit Rate (CBR) or Average Bit Rate (ABR)
models are used and <b><span style="color: red;">~1.30 speedup</span></b> when
Variable Bit Rate (VBR) mode is used on SMT platforms and >1.45x on SMP
systems.'</font><br><br></span>If you say it can't have no speed improvement, then you prove you don't know a thing about programming. <br>I will laugh at you when 8 cores wille be standard in all pc's and you still will say the same :)
<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;"><div style=""><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.
</div></div></blockquote><div><br><br>3) I told you multiple thread support is possible, I gave you an real-life example of the LAME encoder above.<br>I also gave reasons why it would be better: faster encoding speeds, ...
<br>Besides that: you can't decide if I send messages to this list or not, so don't *even* talk about that!<br></div><div><br><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;">
<div style=""><div>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></blockquote><div><br><br>says the guy who tells me supporting multiple threads in the encoding phase of an encoder is impossible and will give NO performance boost (I point you out to LAME MT again that proves you're wrong) ...
<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;"><div style=""><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></blockquote><div><br><br>And you are the first person who thinks he is mister-knows-it-all but gives EXTREME funny and incorrect statements like:<br>- 'multiple core support won't give a performance boost'
<br>- 'it's impossible to implement multiple threads in an audio encoder'<br><br>I recommend you to study IT (like I did) and get your master's degree and after that maybe your PhD.<br>We'll talk again then when you accomplished this :)
<br><br>best regards,<br>Harry <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;"><div style=""><div>Brian W.</div><span class="q">
<div><br></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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
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></div><br></div></div><br></span></div></blockquote>
</div><br>