[Flac-dev] 0.6 release

[Josh Coalson]

--- Mark Powell <M.S.Powell at salford.ac.uk> wrote:
> Josh,
>   Those speed improvements are great. Quick test on
> an 365MB wav of Neil
> Young's eponymous 1st album on a PIII 650E
> (Coppermine) under FreeBSD 4.2:
> 
> 		User	Sys	MB
> 
> shorten23	0:46s	4.0	208.3
> shorten31	1:24s	5.3	208.6
> flac CVS	4:21s	7.5	199.2
> 
> It's getting near to be a useful replacement for
> shorten. Only 3x slower.
>
Good info.  If speed is really an issue, I have one
more change to make that will make -1 only 1.5x
slower than shorten with a little bit better
compression than shorten.

>   Any idea why it uses so much more sys time? I
> would've thought they'd
> all be about the same. I can see why shn31 uses more
> than shn23, because
> it goes and appends that seek table after the
> encoding.
>
don't really know why; the encoding is one-pass.

>   In my limited testing I note that it usually gets
> a few percent better
> than Monkey Audio, but that MA occasionally gets a
> few percent better than
> flac. I've been chatting with the MA author to get
> him to release a
> version of his command line compressor MAC.exe to
> put support for pipes
> in. He says that it will be able to decode to a
> pipe. However, it won't
> encode from a pipe, because it has to know how much
> data it is going to be
> compressing first and then it needs to seek around
> to update header info.
> This is a big win for the obviously more elegant
> design of flac.
>
well, it is a sticky problem.  the windows (or more
specifically, MSVC) version of flac still has pipe
bugs.

basically, if flac knows near the beginning of
encoding what the size of the input is (like from
a wave header), it can output to a pipe correctly
in one pass.  seek support is not index-table based
(it sounds like it is in MAC).

but, if you pass raw samples in from a pipe, it
can't update the header of the output stream with
the number of samples since you can't really seek
backwards within the output pipe.  the encoder will
just put 0 in for the number of samples in the
header.  for this case I plan to add an option to
tell flac the number of samples to expect.

the encoder also calculates other data which it
tries to put in the header after finishing, info
that can, say, help a hardware decoder tell if it's
decode buffers can handle the stream (like min/max
blocksize, min/max framerate).  if you output to
a pipe that data will also be unknown.

none of this would keep the file from playing in a
file-based environment.

>   Keep up the good work Josh. I just wish I knew
> some x86 assembly so I
> could help out with the optimisation.
>
Thanks.  So far though there's no assembly yet...

Josh


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/