Thanks for the quick response on the C++ thing.
It would also be nice if the host program could correctly write the
STREAMINFO block in the stream encoder metadata callback without having
to know the specifics of the header format (or worry about endianness).
How exactly to achieve this might take some thought, but what about this
idea:
1. The correct way to respond to the metadata callback:
i. If this is a seekable stream, seek to the beginning and return
FLAC__STREAM_ENCODER_METADATA_OK (or something).
ii. If this is not a seekable stream, return
FLAC__STREAM_ENCODER_METADATA_NOT_SEEKABLE
2. If the callback indicated that the stream is seekable, FLAC calls
the write callback again, writing 'fLaC' and the STREAMINFO block
(and
any seek tables as well).
What do you think?
Joshua
P.S. I don't think I've ever read any code that so shamelessly refuses
to break at 80 chars. :-) Do you have certain settings in your
editor that makes code formatted this way more readable?
--
Joshua Haberman <joshua@haberman.com>
--- Joshua Haberman <jhaberman@ups.edu> wrote:> Thanks for the quick response on the C++ thing. > > It would also be nice if the host program could correctly write the > STREAMINFO block in the stream encoder metadata callback without > having > to know the specifics of the header format (or worry about > endianness). > How exactly to achieve this might take some thought, but what about > this > idea: > > 1. The correct way to respond to the metadata callback: > i. If this is a seekable stream, seek to the beginning and return > FLAC__STREAM_ENCODER_METADATA_OK (or something). > ii. If this is not a seekable stream, return > FLAC__STREAM_ENCODER_METADATA_NOT_SEEKABLE > 2. If the callback indicated that the stream is seekable, FLAC calls > the write callback again, writing 'fLaC' and the STREAMINFO block > (and > any seek tables as well). > > What do you think?hmm, interesting idea, let me mull this one over.> P.S. I don't think I've ever read any code that so shamelessly > refuses > to break at 80 chars. :-) Do you have certain settings in your > editor that makes code formatted this way more readable?yeah, at some point in my coding life I realized you either have three choices: 1) huffman-encode variable names; 2) artificially break at 80 chars; or 3) pretend everyone's terminal is infinitely wide. #3 seems to have the least negative consequences, but most people still choose #1 or #2. if you pick #1, anyone who reads your code has to either find your dictionary in the comments or discover it with archaeology because there are no comments. if you pick #2 you will always violently offend at least one person's coding standards and they will reformat all your code at the first opportunity. if you pick #3 you can usually have more self-explanatory code and still stay within 160 characteres *most* of the time. with current displays and editors it doesn't seem too demanding. Josh __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
dug up this thread, sorry it so long to respond... --- Joshua Haberman <jhaberman@ups.edu> wrote:> It would also be nice if the host program could correctly write the > STREAMINFO block in the stream encoder metadata callback without > having > to know the specifics of the header format (or worry about > endianness). > How exactly to achieve this might take some thought, but what about > this > idea: > > 1. The correct way to respond to the metadata callback: > i. If this is a seekable stream, seek to the beginning and return > FLAC__STREAM_ENCODER_METADATA_OK (or something). > ii. If this is not a seekable stream, return > FLAC__STREAM_ENCODER_METADATA_NOT_SEEKABLE > 2. If the callback indicated that the stream is seekable, FLAC calls > the write callback again, writing 'fLaC' and the STREAMINFO block > (and > any seek tables as well). > > What do you think?yes, the metadata step at the end of encoding is kind of awkward. your proposal sounds fine. I will think about it some more. anyway, a change like this would break backward compatibility with the libFLAC API, which means it would be a 1.1 think, not a 1.0.x thing. Josh __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com