[Flac-dev] compression

[Harry Sack]

hi

can we expect much better compression (like the step to v. 1.2.x) in
future versions of the flac encoder or are we at maximum compression
level now?

thx
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] general question

[Harry Sack]

hi

is it true flac began on *nix systems and development is still being
done on that platform because i never read things about windows
compilers on the mailing list?

thx
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] compiling win32 version

[Harry Sack]

hi

what compiler is used to compile the flac.exe in the installer: visual
studio or a gcc cross-platform compiler?

thx
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Support .cda as input files

[Harry Sack]

does anybody know why dvd use files for audio and video but audio cd's not?
What could be the reason for this?
e.g. they could make a file for each track and just put them on an
audio cd and make cd players compatible with this format. So for me it
has always been a mystery why audio cd's work this way.

does anybody knows if super audio cd's still work the same as normal ones?

2007/9/13, Josh Coalson <[EMAIL PROTECTED]>:
> --- Daniel Aleksandersen <[EMAIL PROTECTED]> wrote:
>
> > Hi list,
> >
> > I would really like to see support for .cda as input files. The cda
> > format is the one used on regular audio CDs.
>
> if the .cda files appeared as regular files in the filesystem and
> implemented enough of the POSIX stream interface, it is possible,
> but I don't know the what the format of the data is.
>
> otherwise, it really doesn't belong in flac but in a ripping program.
>
> you're the first one to ask though, probably because people using
> FLAC also tend to care about rip quality and the .cda scheme
> would almost have to use burst mode to present a regular file
> interface.
>
> Josh
>
>
>
>
> 
> Need a vacation? Get great deals
> to amazing places on Yahoo! Travel.
> http://travel.yahoo.com/
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Re: multiple core support

[Harry Sack]

2007/9/9, Josh Coalson <[EMAIL PROTECTED]>:
>
> --- Harry Sack <[EMAIL PROTECTED]> 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?
>
> because the tradeoffs I described required for arbitrarily parallel
> encoding significantly complicate the api and implementation.
> libFLAC was not design for multicode file encoding on PCs, it is a
> reference design that is also being used in embedded devices running
> <100MHz, low memory, all kinds of different OSes, etc.



euh :) Just make a flag or something in the api that enables the code for
low cpu power devices and/or streaming and disable this when encoding on
fast pc (so no streaming)? So it uses file based code then for encoding of
files on pc's with multiple cpu's and stream based code for all other
devices and streaming :)
Then you have both in the API!

> 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
>
> an api cannot be all things to everyone.



sure it can: you just have to make some different cases (low cpu power
device/streaming or multi-core cpu) and call the apprioprate functions




you keep making this
> assertion but if you actually tried to implement it (and I hope
> you will) the problems we are all bringing up will quickly become
> obvious.
>
> your own lame-mt example is not an incremental improvement but a
> significant rewrite of lame (and also does not have nearly the
> performance advantage of process-level parallelism, see
> http://www.hydrogenaudio.org/forums/index.php?showtopic=50862)


It's multi-threaded and that's what I mean: people here say an audio codec
can't be written multi-threaded and it will give no performance boost:
1) that's false: se LAME MT
2) performance boost up to 30%: see LAME MT again

For very large files you must wait not so long before it's encoded vs. the
original LAME.

> > 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?
>
> you can assume libFLAC will probably not have it.  if you can modify
> libFLAC to make a multithreaded encoder like flac-mt that would be
> neat and probably useful to some people.  until that time there is
> not much point repeating the same assertions which are just going to
> aggravate people.
>
> Josh
>
>
>
>
>
> 
> Building a website is a piece of cake. Yahoo! Small Business gives you all
> the tools to get online.
> http://smallbusiness.yahoo.com/webhosting
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Re: multiple core support

[Harry Sack]

2007/9/8, Brian Willoughby <[EMAIL PROTECTED]>:
>
> Harry,
>
> 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.
>


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 :)
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 ...
Please read carefully what I write :)

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.
>


2) you really show you have no good knowledge about programming. There are
several codecs out there that  try to use multiple cores.
To give a concrete example: http://www.lame-mt.com/
Here is the prove there is a HUGE performance boost:

'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 *~1.16x speedup* when
Constant Bit Rate (CBR) or Average Bit Rate (ABR) models are used and *~1.30
speedup* when Variable Bit Rate (VBR) mode is used on SMT platforms and >
1.45x on SMP systems.'

If you say it can't have no speed improvement, then you prove you don't know
a thing about programming.
I will laugh at you when 8 cores wille be standard in all pc's and you still
will say the same :)

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.
>


3) I told you multiple thread support is possible, I gave you an real-life
example of the LAME encoder above.
I also gave reasons why it would be better: faster encoding speeds, ...
Besides that: you can't decide if I send messages to this list or not, so
don't *even* talk about that!



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.
>


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) ...

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.
>


And you are the first person who thinks he is mister-knows-it-all but gives
EXTREME funny and incorrect statements like:
- 'multiple core support won't give a performance boost'
- 'it's impossible to implement multiple threads in an audio encoder'

I recommend you to study IT (like I did) and get your master's degree and
after that maybe your PhD.
We'll talk again then when you accomplished this :)

best regards,
Harry

Brian W.
>
>
> 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 

Re: [Flac-dev] Re: multiple core support

[Harry Sack]

2007/9/8, Scot Thompson <[EMAIL PROTECTED]>:
>
>  No, streams should stay.  Audio is NOT a file based process -- it's a
> stream.  You can't listen to an entire song simultaneously.  You organize it
> into files for later use, but you listen and record from a stream.
> Stream-based storage is practically REQUIRED for an audio codec.  It's not
> random access, it's sequential.  You can put wrappers around it to make it
> convenient for file storage and conversions, but the codec itself must be
> streams.
>
> Multi-core support may not be practical for a variable-length encoding.
> How would you know where to write the next block when you don't know what
> size the first block is going to be?  The functionality for that is not
> trivial and is not currently implemented in the API.
>
> Maybe somebody will write a multi-core file-based wrapper for you, or
> maybe you could try writing one yourself.  Or if you disagree with Josh
> about the direction of FLAC you can write your own codec.  But your
> nattering on and on about how you think the API isn't right doesn't help at
> all and is very annoying.
>


I just say that the way it is now it's IMpossible to make multiple core
support, that's all. It's just a fact :)

Harry

--
> *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On
> Behalf Of *Harry Sack
> *Sent:* Saturday, September 08, 2007 6:06 AM
> *To:* Brian Willoughby
> *Cc:* flac-dev@xiph.org
> *Subject:* Re: [Flac-dev] Re: multiple core support
>
>
>
> 2007/9/8, Brian Willoughby <[EMAIL PROTECTED]>:
> >
> > Ralph,
> >
> > The problem is that there is no clear advantage, at least in terms of
> > multiple cores, to the approach you're asking about.  In order to
> > allow each stage of the codec to overlap, you need smart buffering
> > between each stage.  That adds code and complexity which isn't there
> > currently.  So you end up making the system do more work in the hopes
> > that there will be some overlap.  Basically, later stages get blocked
> > waiting for their input buffer to fill, which means that you're not
> > really getting very much overlap at all, but plenty of multi-
> > threading overhead.  At least that's the predicted result - I admit
> > that nobody has tried this, to my knowledge.
>
>
>
> this is because of the limitations/design problem of FLAC API in
> particular. When the developers had made a smart decision and based
> everything on file based I/O you would get a HUGE performance boos when
> using multiple threads divided between multiple cores, because they only
> thing to do was to split the file output in different threads.
> But it's not clear to me why everything was based on streams...
>
> Harry
>
> Brian Willoughby
> > Sound Consulting
> >
> >
> > On Sep 7, 2007, at 18:25, Ralph Giles wrote:
> >
> > On Fri, Sep 07, 2007 at 04:59:50PM -0700, Josh Coalson wrote:
> >
> > > 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.
> >
> > It seems like buffering (especially compressed) blocks and writing them
> > to the stream in sequence wouldn't be a problem. Is there something in
> > the way the blocking decisions are made that makes it hard to divide the
> > input audio this way?
> >
> >   -r
> >
> > ___
> > Flac-dev mailing list
> > Flac-dev@xiph.org
> > http://lists.xiph.org/mailman/listinfo/flac-dev
> >
>
>
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Re: multiple core support

[Harry Sack]

2007/9/8, Brian Willoughby <[EMAIL PROTECTED]>:
>
> Ralph,
>
> The problem is that there is no clear advantage, at least in terms of
> multiple cores, to the approach you're asking about.  In order to
> allow each stage of the codec to overlap, you need smart buffering
> between each stage.  That adds code and complexity which isn't there
> currently.  So you end up making the system do more work in the hopes
> that there will be some overlap.  Basically, later stages get blocked
> waiting for their input buffer to fill, which means that you're not
> really getting very much overlap at all, but plenty of multi-
> threading overhead.  At least that's the predicted result - I admit
> that nobody has tried this, to my knowledge.



this is because of the limitations/design problem of FLAC API in particular.
When the developers had made a smart decision and based everything on file
based I/O you would get a HUGE performance boos when using multiple threads
divided between multiple cores, because they only thing to do was to split
the file output in different threads.
But it's not clear to me why everything was based on streams...

Harry

Brian Willoughby
> Sound Consulting
>
>
> On Sep 7, 2007, at 18:25, Ralph Giles wrote:
>
> On Fri, Sep 07, 2007 at 04:59:50PM -0700, Josh Coalson wrote:
>
> > 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.
>
> It seems like buffering (especially compressed) blocks and writing them
> to the stream in sequence wouldn't be a problem. Is there something in
> the way the blocking decisions are made that makes it hard to divide the
> input audio this way?
>
>   -r
>
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Re: multiple core support

[Harry Sack]

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?

thx

--- Harry Sack <[EMAIL PROTECTED]> wrote:
>
> > 2007/9/7, Avuton Olrich <[EMAIL PROTECTED]>:
> > >
> > > On 9/6/07, Harry Sack <[EMAIL PROTECTED]> wrote:
> > > > it's really not complicated I think: only api changes to write on
> > any
> > >
> > > Please get started writing a patch, immediately.
> >
> >
> >
> > I'm just an IT student and I have no time for that :)
> > I also didn't study the flac API in detail but I know it's perfectly
> > possible because I made a avi encoder running on multiple threads
> > once and
> > it's exactly the same for audio data.
> >
> > --
> > > avuton
> > > --
> > > Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
> > >
> > > ___
> > Flac-dev mailing list
> > Flac-dev@xiph.org
> > http://lists.xiph.org/mailman/listinfo/flac-dev
> >
>
>
>
>
>
> 
> Building a website is a piece of cake. Yahoo! Small Business gives you all
> the tools to get online.
> http://smallbusiness.yahoo.com/webhosting
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] Re: multiple core support

[Harry Sack]

2007/9/7, Brian Willoughby <[EMAIL PROTECTED]>:
>
> I really should have just said that it will require some testing to
> make sure the FLAC API can handle writing the same file from multiple
> threads.  It may not turn out to be complicated at all.
>
> The FLAC decoder has its own code for writing PCM files already.
> Tweaking this to support multi-threaded writes would not be too
> difficult.  It's simply a matter of building the PCM file, setting
> aside the data area for the PCM samples, and then providing each
> thread with information needed to write at different offsets.  FLAC
> never needs to "check for valid PCM streams" since it is creating the
> PCM stream from scratch every time.



But it's not 100% lossless if you don't check it when written using
different threads. Now there is only 1 thread that writes at the back of the
file in a lineair way. So the chance there is an error when decoding is
almost non existing because it just write the new block at the end of the
file till it's finished.

If you write the file in parts at different locations inside the pcm file on
even different cpu's, there are certainly things that can go wrong. And you
say there is no need to check those resulting pcm streams ... So this makes
no sense: what if there was something wrong with 1 thread on 1 cpu (maybe a
synchronisation problem, ...)? Then there would be missing pcm blocks or
even corrupted ones (because they are written at different locations in the
file while running different threads on differents cpu's). So making
decoding to support multiple cores is not easy as it sounds. There really
has to be a 'checking' phase at the end to verify if the pcm stream was
build up correctly using the different threads. If you don't check here, you
risk getting non-lossless stream because of missing/corrupted blocks and
this is exactly what a lossless codec doesn't want!

At the encoding end there you can automatically check the resulting flac
file using the verify option. So after running the multiple threads on the
pcm stream that results in the flac file, you just check that resulting flac
file using verify to see if the md5 checksum matches. So if something went
wrong in some thread and there were missing blocks/corrupted ones, you will
get a different md5 and you know exactly something went wrong and you just
repeat the encoding process till everything is correct. At the decoding end
you can't see this when using multiple threads because there is no way to
check if the pcm stream was built up correctly (at least: as far as I know)



Recording always involves a PCM data buffer.  You're correct that
> there might be a 2 CPU split, automatically, depending upon the
> system.  However, I was simply stating that going to an arbitrary
> number of threads would not be possible when recording, since you're
> only getting one block at a time, and the block is where the division
> between CPUs would be made.



yes of course: but recording has nothing do to with the encoder itself. The
recording part happens in other software. You just get raw pcm data to
encode, just like when encoding an existing file. There is really no
difference because you can let the recording software say write x blocks of
pcm data and you just encode these using multiple threads to flac. So it's
perfectly possible to do it here too, but it's not really needed. It's only
useful for encoding existing files.

Harry

Brian W.
>
>
> On Sep 6, 2007, at 17:24, Harry Sack wrote:
>
> it's really not complicated I think: only api changes to write on any
> position in the file if that's not possible already with existing
> function.
>
> I'm not sure if decoding can have multi-core support: you need an api
> for writing pcm files in different parts then and this is maybe more
> difficult to check if it's valid pcm data since the decoder can only
> check for valid flac streams , not pcm streams i think.
>
> you can make recording also support multi cores: just let cpu 1 fill a
> pcm data buffer while cpu 2 encodes it. In this case you have a more
> reliable encoding with less cpu usage of your system (it's spread
> among 2 cpu's)
>
>
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Re: multiple core support

[Harry Sack]

2007/9/7, Avuton Olrich <[EMAIL PROTECTED]>:
>
> On 9/6/07, Harry Sack <[EMAIL PROTECTED]> wrote:
> > it's really not complicated I think: only api changes to write on any
>
> Please get started writing a patch, immediately.



I'm just an IT student and I have no time for that :)
I also didn't study the flac API in detail but I know it's perfectly
possible because I made a avi encoder running on multiple threads once and
it's exactly the same for audio data.

--
> avuton
> --
> Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] Re: multiple core support

[Harry Sack]

it's really not complicated I think: only api changes to write on any
position in the file if that's not possible already with existing
function.

I'm not sure if decoding can have multi-core support: you need an api
for writing pcm files in different parts then and this is maybe more
difficult to check if it's valid pcm data since the decoder can only
check for valid flac streams , not pcm streams i think.

you can make recording also support multi cores: just let cpu 1 fill a
pcm data buffer while cpu 2 encodes it. In this case you have a more
reliable encoding with less cpu usage of your system (it's spread
among 2 cpu's)


2007/9/7, Brian Willoughby <[EMAIL PROTECTED]>:
> Hmm,
>
> You're actually correct, when you put it that way.  Because the audio
> blocks are coded independently, you could speed things by having the
> encoder (or decoder) do a little up-front processing on the metadata,
> then use the overall settings to divide the file into sections and
> run the FLAC process in parallel.  However, I think it is generally
> frowned upon in some circles to create one thread per processor,
> rather than making the division dependent upon some other factor that
> is actually independent of the number of processors.  Apart from that
> caveat, someone could certainly develop an encoder or decoder which
> uses the FLAC library API to implement a threaded encoder/decoder -
> well, assuming that the API can write to subsets of a file, instead
> of requiring that the entire file be written from start to finish -
> and also assuming that the API can run in multiple threads and write
> to the same file.
>
> By your method, decoding would be faster, too.  Not everybody decodes
> just to listen.  Some of us keep original masters in FLAC format for
> archival purposes, but need the whole thing decoded before we can mix
> and master.  Anything which speeds up decoding would help get work
> done faster.
>
> On the flip side, another thing to consider is that not all encoding
> is done with files that already exist.  If you are recording live to
> FLAC, you cannot multi-thread the encoder because you don't have any
> audio besides the current block.
>
> So, decoding for playback and encoding for recording are two examples
> which cannot be multi-threaded.  But file format conversion could be
> developed to take advantage of multiple processors.  It would require
> a lot of tweaks to the library, perhaps.
>
> Note: PC games are multi-threaded because they're already doing
> several different things at once.  Sometimes the complexity is
> actually reduced by dedicating a thread to each part of the game
> logic.  And precisely because there are so many different things
> going on, multi-threading can speed things up when they overlap in
> unpredictable ways.  Games would be harder to write in a single-
> threaded way.  Meanwhile, encoding/decoding FLAC is easier to write
> in a single-threaded design.
>
> Brian W.
>
>
> On Sep 6, 2007, at 16:42, Harry Sack wrote:
>
> yes, i totally agree but I'm talking about the ENcoder :)
> You can perfectly 'cut' the pcm stream 'in half' and let 1 cpu encode
> one part , the other 2nd part (or with 4 cpu's in 4 parts, ...),
> because it's just a stream one frame after the other,  as far as i
> know (correct me if i'm wrong).
> Many pc games synchronise multiple threads on 2 (even 4!) cores (much
> More complicated then reading frames, compressing, writing compressed
> frames like the encoder does), so i think making the encoder support 2
> cpu's is perfectly possible.
>
> of course adding multi-core support to the decoder is silly because
> it's not necessary (any single core cpu is fast enough to play 1 file
> and it would only slow it down)!
>
> 2007/9/7, Brian Willoughby <[EMAIL PROTECTED]>:
> > Any software which supports multiple processors must be multi-
> > threaded.  The process of designing multi-threaded code adds
> > complexity to the software, so there must be a good reason to go
> > through all the trouble.  The procedure for decoding a single file
> > could only benefit marginally from being multi-threaded, because most
> > operations would need to wait until the previous operation was
> > completed.  One section of the decoder might be able to process
> > several blocks, but the overall result would still need to wait until
> > all blocks are completed.  Besides, managing dynamic buffers between
> > each step of the decoding process would actually require the decoder
> > to do more, meaning it would slow down to an extent.  There would
> > pretty much be no difference in the total time, whether single
&g

[Flac-dev] FLAC: compression ratio

[Harry Sack]

hi flac-dev list!

I see, when compressing CD-audio tracks, I can reach up to 60% (ratio = 0.6x)
of the original WAV file after compression. I was wondering if the FLAC
codec could become as good as reaching 50% of the original WAV file in the
future or if we are already at the (almost) maximum compression possible?

thx
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] FLAC: general question

[Harry Sack]

hi dev'ers

is it true flac is developed in linux by Josh and later compiled in windows?

I was also wondering if Josh implemented the flac encoder/decoder all
by himself ?

just some questions because I'm interested in flac in general :)

thx
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] FLAC: library for C#

[Harry Sack]

2007/6/14, Josh Coalson <[EMAIL PROTECTED]>:


--- Erik de Castro Lopo <[EMAIL PROTECTED]> wrote:
> Harry Sack wrote:
>
> > Hi FLAC dev's list,
> >
> > I'm looking for a library for the C# language (Microsoft .Net
> > Framework 2.0or higher) to play FLAC files and/or maybe do some
> other
> > things like getting
> > the file duration, file properties, ... of FLAC files.
> > The library must preferably be free (open source is not required,
> but is
> > always nice).
>
> Why not just build FLAC as a DLL and then call into the DLL from C#?

Harry, if that is good enough, there are already pre-build DLLs
with headers in the sourceforge download section.




but aren't they C++ headers en lib's? I have no idea how I can include a C++
header in a C# project.
It this even possible?

thx

Josh







Get the Yahoo! toolbar and be alerted to new email wherever you're
surfing.
http://new.toolbar.yahoo.com/toolbar/features/mail/index.php
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] FLAC: library for C#

[Harry Sack]

Hi FLAC dev's list,

I'm looking for a library for the C# language (Microsoft .Net
Framework 2.0or higher) to play FLAC files and/or maybe do some other
things like getting
the file duration, file properties, ... of FLAC files.
The library must preferably be free (open source is not required, but is
always nice).
I hope somebody can help me with this!

thx
Harry
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] compression ratio

[Harry Sack]

2007/5/14, Josh Coalson <[EMAIL PROTECTED]>:


--- Harry Sack <[EMAIL PROTECTED]> wrote:
> hi
>
> i was wondering if it's possible to tell me what the theoretical best
> compression ratio the flac encoder can do, because i was wondering
> what the future of flac will bring us. So this question is probably
> best addressed to Josh: can we suspect much better compression ratio
> in the future or is the encoder already at his *almost* peak
> compression level.

I think you're talking about average compression ratio because it
depends on the particular sample.  to make significant improvements
(>3%) would require changes to the format that wouldn't work with
older decoders, which I don't plan on ever doing.




i think that's a very good decision!

if you look at the comparison here:

  http://flac.sourceforge.net/comparison.html
you will see that FLAC is already within 3-4% of the most aggresive
codecs.




so in the future we can expect mostly speed improvements for
encoder/decoder?

Thanks

Josh





Boardwalk
for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's
economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow

___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] compression ratio

[Harry Sack]

hi

i was wondering if it's possible to tell me what the theoretical best
compression ratio the flac encoder can do, because i was wondering
what the future of flac will bring us. So this question is probably
best addressed to Josh: can we suspect much better compression ratio
in the future or is the encoder already at his *almost* peak
compression level.

thx in advance!
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] flac tools ppc

[Harry Sack]

hi,

i'm looking for the flac tools  (flac ,metaflac) for windows mobile (pocket pc).
are they available somewhere ?
thx
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] FLAC: Windows wildcards support

[Harry Sack]

Hi,

I have read this on the sourceforge site:

Windows wildcards support for FLAC and Metaflac  *Private:
(?)
*
No   The Linux shell support wildcards but not the Windows
shell.
Would it be possible to add wildcard support for
Windows?

Example with Windows:
metaflac --add-replay-gain *.flac

Gives the following error:
*.flac: ERROR: reading metadata, status
= "FLAC__METADATA_CHAIN_STATUS_ERROR_OPE
NING_FILE"

And Josh answered this in 2004:


"Date: 2004-03-25 17:29

Sender: jcoalson [image:
Project Admin] 

Logged In: YES
user_id=78173

yes, this will be added in the next release.
Josh"

Now I was wondering if windows wildcards support is still planned to
be implemented in the FLAC and METAFLAC
command line tools, because wildcards still don't work in version
1.1.4 (in windows).

thanks in advance!
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Re: FLAC: same features as WavPack

[Harry Sack]

2007/3/29, Brian Willoughby <[EMAIL PROTECTED]>:



On Mar 29, 2007, at 12:44, Harry Sack wrote:

2007/3/29, Josh Green <[EMAIL PROTECTED]>:
>
> As far as I know 24 bit FLAC support is broken.  It often doesn't
> compress the audio at all, but instead stores the chunks as verbatim
> type (although the FLAC format supports 24 bit).  Perhaps this is fixed?

If so, do let me know.


I also want to know if this is fixed.


Harry, your question doesn't make it clear as to whether you're actually
having a problem, or just curious about the answer.  Josh Green says he's
having a problem where compression doesn't seem to work.  Harry, are you
actually seeing a problem with 24-bit?  What is the problem you're seeing?
Are you just writing in because you're curious about the status?




yes sorry, I was just curious about the status, I have never tried 24-bit
myself.

There actually is no problem with 24-bit support, as I stated earlier.  So

before people start chiming in with "me too" - I'd like to request that you
actually say what problem you're seeing, along with a few details.  Let's
not start a rumor fest here.


I agree that perhaps 32 bit float/pcm isn't
> entirely necessary when it comes to storing different qualities.  But
> when wanting to preserve floating point audio, I would think it would be
> a nice feature.  I believe 32 bit floats have a precision of 23 bits
> when the audio is +/- 1.0, so in theory that would mean that 24 bit
> would have more precision but less dynamic range (if the floating point
> range is outside of +/- 1.0).


Is it possible to explain me a bit further what "less dynamic range"
exactly means? Can this difference actually be heard and if yes, in what
audio quality sources? I have just discovered FLAC and I'm not an audio
professional, but I wanted to know what the "real" difference between 32 bit
float and 24 bit int precission is when comparing audio quality.


You cannot hear 32-bit audio because there is no such thing as a 32-bit
digital-to-analog converter.  And there is absolutely no floating-point D/A
of any bit-depth.  So you cannot compare the audio quality of 32-bit to
anything.  All digital audio must be converted to 24-bit or less before you
can hear it.  This conversion is not part of FLAC, so you probably should
look elsewhere to learn about general digital audio technology.

FLAC is lossless when compressing any audio that comes from an A/D.  FLAC
is lossless when compressing any audio that is properly prepared for D/A,
and thus ready for listening.  Any other format not supported by FLAC is an
intermediate format used by audio engineers and not typically for
distribution, except perhaps in scientific circles.

Note: there are non-linear DACs for 8-bit codes, but those are not true
floating point, even though the bit code has a mantissa and exponent.


And I'm also guessing for reasons why WavPack actually uses 32 bit floats.
Is it true then that FLAC is not completely lossless if you look at the
encoder when using 24 bit int's vs. using 32 bit float's? Does this storage
thing influences the audio quality of just regular Audio-CD quality (16
bits, 44.1 kHz, stereo) after compression, because that's the main reason
I use FLAC.


Lossless means lossless.  16/44.1 CDDA audio quality is identical before
and after FLAC.  CDDA audio does not use 24-bit or 32-bit codes at any
point.  It is all 16-bit integers.

FLAC does not support 32-bit float, so it is pointless to say whether it
is completely lossless when storing 32-float as 24-bit int.  If you convert
32-float to 24-bit outside FLAC, then the loss occurs elsewhere, not in
FLAC.  FLAC is completely lossless for all formats that it supports.  I'm
sorry that I confused things in my earlier message by pointing out that you
can convert 32-bit float to a format that FLAC supports or that you can
write your own encoder/decoder for 32-bit integer FLAC.  You really need to
understand floating point numbers and what kind of audio data you have
before trying to analyze FLAC this way.




thanks, now it's all clear for me !

Brian Willoughby

Sound Consulting


___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Re: FLAC: same features as WavPack

[Harry Sack]

2007/3/29, Josh Green <[EMAIL PROTECTED]>:


Hello FLAC list.




Hi Josh,

As far as I know 24 bit FLAC support is broken.  It often doesn't

compress the audio at all, but instead stores the chunks as verbatim
type (although the FLAC format supports 24 bit).  Perhaps this is fixed?


If so, do let me know.



I also want to know if this is fixed.



I agree that perhaps 32 bit float/pcm isn't

entirely necessary when it comes to storing different qualities.  But
when wanting to preserve floating point audio, I would think it would be
a nice feature.  I believe 32 bit floats have a precision of 23 bits
when the audio is +/- 1.0, so in theory that would mean that 24 bit
would have more precision but less dynamic range (if the floating point
range is outside of +/- 1.0).



Is it possible to explain me a bit further what "less dynamic range" exactly
means? Can this difference actually be heard and if yes, in what audio
quality sources? I have just discovered FLAC and I'm not an audio
professional, but I wanted to know what the "real" difference between 32 bit
float and 24 bit int precission is when comparing audio quality. And I'm
also guessing for reasons why WavPack actually uses 32 bit floats. Is it
true then that FLAC is not completely lossless if you look at the encoder
when using 24 bit int's vs. using 32 bit float's? Does this storage thing
influences the audio quality of just regular Audio-CD quality (16
bits, 44.1kHz, stereo) after compression, because that's the main
reason I use FLAC.

thanks in advance!


The conversion to 24 bit would be a

problem in that case.

Best regards,
Josh Green


On Thu, 2007-03-29 at 12:07 -0700, Brian Willoughby wrote:
> Hi Henry,
>
> 32-bit float has exactly the same precision as 24-bit int.  I'm not
> sure what the reference encoder does, but it would be possible to
> write an encoder based on the FLAC library which converts 32-bit
> float to 24-bit int when creating a FLAC-compressed file.  You could
> also do the 32-bit float-to-24-bit int conversion with another tool
> before using the standard flac encoder.  There would be no loss of
> data so long as the original audio does not exceed +-1.0 in floating
> point, in which case you'd need some way to handle clipping.  32-bit
> float really only has an advantage for intermediate stages of audio
> processing where it might not be a good thing to require clipping or
> peak limiting until a later stage.
>
> 32-bit int has more precision than 32-float, albeit less dynamic
> range.  However, there are no 32-bit A/D converters out there, and we
> really only need about 18.5 bits in any listening environment, so 32-
> bit integer is not very useful.  It shouldn't be difficult to write
> an encoder/decoder which supports 32-bit integer.  There is at least
> one independent FLAC implementation, but I have no idea whether it is
> open-source or supports 32-bit.
>
> As it stands, FLAC is perfectly suited for compression and archival
> of all original recordings and all final masters of audio material.
> Only engineers and experimental researchers would need 32-bit for
> their intermediate storage, and I believe it is typical to not
> compress intermediate storage anyway.  In other words, there's no
> real point for this support in FLAC, which is why it isn't there.
>
> Do you have a specific need?  ... other than to see the support
> listed as a bullet item on the feature list?
>
> Brian Willoughby
> Sound Consulting
>
>
> On Mar 29, 2007, at 10:24, Harry Sack wrote:
>
> Hi,
>
> I have read this on a forum:
>
> 'FLAC supports 24-bit audio fine. My understanding is that the FLAC
> format also handles 32-bit ints, but the reference encoder does not
> implement it, and FLAC has no support for float data. WavPack handles
> all integer bitdepths up to 32-bit and also 32-bit floats.
>
> Both codecs handle all sampling rates.'
>
> I was wondering if there are plans to support 32-bit ints and float
> data in the future, like WavPack does.
>
> thanks in advance
>



___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] Re: FLAC: same features as WavPack

[Harry Sack]

2007/3/29, Brian Willoughby <[EMAIL PROTECTED]>:


Hi Henry,

32-bit float has exactly the same precision as 24-bit int.  I'm not
sure what the reference encoder does, but it would be possible to
write an encoder based on the FLAC library which converts 32-bit
float to 24-bit int when creating a FLAC-compressed file.  You could
also do the 32-bit float-to-24-bit int conversion with another tool
before using the standard flac encoder.  There would be no loss of
data so long as the original audio does not exceed +-1.0 in floating
point, in which case you'd need some way to handle clipping.  32-bit
float really only has an advantage for intermediate stages of audio
processing where it might not be a good thing to require clipping or
peak limiting until a later stage.

32-bit int has more precision than 32-float, albeit less dynamic
range.  However, there are no 32-bit A/D converters out there, and we
really only need about 18.5 bits in any listening environment, so 32-
bit integer is not very useful.  It shouldn't be difficult to write
an encoder/decoder which supports 32-bit integer.  There is at least
one independent FLAC implementation, but I have no idea whether it is
open-source or supports 32-bit.

As it stands, FLAC is perfectly suited for compression and archival
of all original recordings and all final masters of audio material.
Only engineers and experimental researchers would need 32-bit for
their intermediate storage, and I believe it is typical to not
compress intermediate storage anyway.  In other words, there's no
real point for this support in FLAC, which is why it isn't there.

Do you have a specific need?  ... other than to see the support
listed as a bullet item on the feature list?




Hi,

I was just wondering why WavPack has implemented this feature (what the
possible reason could be) and why FLAC didn't implement it.
Can you give me some reasons WavPack has this feature?

thanks in advance

Brian Willoughby

Sound Consulting


On Mar 29, 2007, at 10:24, Harry Sack wrote:

Hi,

I have read this on a forum:

'FLAC supports 24-bit audio fine. My understanding is that the FLAC
format also handles 32-bit ints, but the reference encoder does not
implement it, and FLAC has no support for float data. WavPack handles
all integer bitdepths up to 32-bit and also 32-bit floats.

Both codecs handle all sampling rates.'

I was wondering if there are plans to support 32-bit ints and float
data in the future, like WavPack does.

thanks in advance


___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] FLAC: same features as WavPack

[Harry Sack]

Hi,

I have read this on a forum:

'FLAC supports 24-bit audio fine. My understanding is that the FLAC format
also handles 32-bit ints, but the reference encoder does not implement it,
and FLAC has no support for float data. WavPack handles all integer
bitdepths up to 32-bit and also 32-bit floats.

Both codecs handle all sampling rates.'

I was wondering if there are plans to support 32-bit ints and float data in
the future, like WavPack does.

thanks in advance
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] FLAC algorithms

[Harry Sack]

Hi,

Is there some documentation available about the algorithms FLAC uses?
I'm talking about some high-level descriptions of the algorithms, which I
can read without having to understand the source code.

thanks in advance
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] FLAC library for the Microsoft .Net Framework

[Harry Sack]

Hi,

Does there exist a FLAC library for the Microsoft .Net Framework for using
with C#?

thanks
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] FLAC: windows installer not up-to-date

[Harry Sack]

Hi,

I wanted to let the FLAC developers know the windows installer (
http://cyberial.com/flacinstaller.asp) is still the old 1.1.3 version

Harry
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] FLAC: best ripping software?

[Harry Sack]

Hi,

I was hoping somebody could answer me this question:. I'm looking for the
best audio CD ripper software, maybe somebody can tell me what you think is
the best ripper available? The operating system it runs on is not important,
I just want to know what's considered the best audio cd ripping software.
In this way I want to make perfect input WAV files for the FLAC encoder.

thanks in advance!
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] FLAC winamp plugin

[Harry Sack]

Hi,

What is the best way to play FLAC files in winamp?

Using the in_flac.dll plugin provided in the flac-1.1.4-win.zip file and
copying it to the Plugins subdirectory of winamp
or
using the plugin that's provided by winamp itself?
Are there differences between those 2 plugins? It's not really clear for me

thanks in advance
Harry
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] FLAC: players for Pocket PC

[Harry Sack]

hi,

I don't know if this message belongs on the mailing list, so sorry if it is
not for this mailing list.

I was wondering if somebody knows a player for Pocket PC (windows mobile
2003) that can play FLAC files on the Pocket PC.

thanks in advance!
Harry
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] FLAC 1.1.4 installation problem

[Harry Sack]

Hi,

I want to compile and install FLAC 1.1.4 from source code and I have
run this like explained in the README: ./configure && make && make
install

I have left out the "make check".

Everything builds OK and is installed. But then when I want to run
"flac", I get this error:

$ flac
flac: error while loading shared libraries: libFLAC.so.8: cannot open
shared object file: No such file or directory

I hope somebody can tell me what the problem is. Please pay attention
that I'm a FLAC beginner.

some version numbers of my system:

autoconf-2.60-21
automake-1.9.6-35
libtool-1.5.22-34

thanks in advanc
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev