<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV>You're brilliant, Harry. Lame MT running on 2 threads runs at 120% while Lame (standard) running on 2 processes runs at 200%. If you still prefer only 120% over 200%, then you can continue to believe that multithreading this kind of algorithm is "smart" - I guess you weren't paying attention when folks on this mailing list suggested that you are far better off running FLAC multiple times on a multiprocessor machine compared to any small speedup you might get from multithreading.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Brian</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR><DIV><DIV>On Nov 2, 2007, at 06:23, Harry Sack wrote:</DIV><BR><DIV><SPAN class="gmail_quote">2007/11/2, 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;">I worked for Microsoft for 4 years, and have been programming audio<BR>software for 25 years (starting many years before WAV or RIFF was<BR>invented).</BLOCKQUOTE><DIV><BR>haha, that explains why you give such stupid answers like 'making the encoder support multiple threads won't speed it up' while other encoders (like <FONT size="-1"><B>LAME MT</B></FONT>) have nice speed boosts when doing this ...<BR><BR class="khtml-block-placeholder"></DIV></DIV></DIV></BODY></HTML>