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.
Besides, the API has support for seekable streams and files.
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.
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.
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.
On Sep 8, 2007, at 06:02, Harry Sack wrote:
2007/9/8, Josh Coalson <[EMAIL PROTECTED]>:
it actually is complicated. the libFLAC api is not suited to a
multithreaded design because the i/o is stream-based, not file-
based. flac(.exe) is the file-based wrapper around libFLAC that
allows it to work on files. the way libFLAC buffers data is also
impossible to parallelize without significantly changing the api.
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)
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
it would take a specialty file-based encoder using an independent
frame encoder to do and even that is not trivial.
so we can assume that those API changes will never come and the flac
encoder will never have multiple core support?
Flac-dev mailing list