similar to: [PATCH] Fix option names in documentation and help messages.

--- man/flac.1 | 25 +++++++++++++++++++++---- man/flac.sgml | 2 ++ 2 files changed, 23 insertions(+), 4 deletions(-) diff --git a/man/flac.1 b/man/flac.1 index fef4ded..3d7bd50 100644 --- a/man/flac.1 +++ b/man/flac.1 @@ -68,6 +68,9 @@ Prefix each output file name with the given string. This can be useful for enco \fB--delete-input-file \fR Automatically delete the input file after

--- doc/html/documentation_tools_flac.html | 6 ++--- include/FLAC/stream_encoder.h | 42 +++++++++++++++++----------------- src/flac/main.c | 20 ++++++++-------- 3 files changed, 34 insertions(+), 34 deletions(-) diff --git a/doc/html/documentation_tools_flac.html b/doc/html/documentation_tools_flac.html index 9f85a25..0964cd2 100644 ---

For some reason all documentation lists the max rice partition order to be 16, while the maximum is 15. This fixes flac -H, the man page and the HTML source code documentation --- doc/html/documentation_tools_flac.html | 2 +- man/flac.1 | 8 ++++---- man/flac.sgml | 8 ++++---- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git

stream_encoder.c has the following code: /* try to keep qlp coeff precision such that only 32-bit math is required for decode of <=16bps streams */ if(subframe_bps <= 16) { ... But FLAC can convert 16-bit input to 17-bit if mid-side coding is used. So, does it make sense to compare subframe_bps with 17? (The patch is attached. What do you think about it?) -------------- next part

Dear list Sorry to ask a user's question on developer list. I didn't find the user list. I am experimenting with --cuesheet and encoded a flac file with a cuesheet. Result is: * Totem on opensuse 10.2 opens the flac file with no meta data, no play list. "Next" button doesn't work; * Mplayer on opensuse 10.2 opens the flac file with no meta data,

Hi all, I was investigating the behaviour of the -p switch of flac. This switch should enable exhaustive search for the optimal qlp coefficient precision, but the resulting files are usually 0.5% larger then when not using the switch. I stumbled upon this code in stream_encoder > if(encoder->protected_->do_qlp_coeff_prec_search) { > min_qlp_coeff_precision =

Ok, I just did a comparison of 1.2.1 with 1.3.2, and the change you're suggesting was already there before. So, now the question becomes: why was the code changed in the first place? Was there a bug that was fixed by changing 17 to 16, or did someone just get overzealous in a code review and thought that 17 was a bad choice? Perhaps 32 bits isn't actually large enough to handle the

--- "David W. Tamkin" <dattier@panix.com> wrote: > First, as long as you don't use the --cuesheet option when you > encode, are > .flac files encoded by 1.1.0 still readable by earlier versions? that's right. > Second, if the old default for seekpoints was -S100x and the new one > is -S10s, > does that mean that, if you encode a 44.1-ksps WAV that was

Hello, I have used --import-cuesheet-from= to insert the cue points, which are OK according to "--export-cuesheet-to=-". The points I invoke are: - the possibility to specify them as frame count instead of time - the doc: i would not find in which format cue/seekpoints are stored in the headers - titles: apparently they get lost with this option. I guess they would be preserved if put

When using the -p switch during encoding, the encoder should try different qlp predictor precision steps. However, some faulty code was too severely restricting the possible steps. This patch lifts the restriction to match a restriction coded a little further in the process. This doesn't make using -p worth your while, but at least it doesn't create larger files now ---

You should read the manual for the FLAC command line utilities. There are many options that would probably achieve what you desire. In particular, one of the links that I sent below clearly leads you to a page describing how cuesheets are related to the SEEKTABLE, and you can create a --seekpoint= marker for each track. Sometimes you really need to take the time to read everything

--- "David W. Tamkin" <dattier@panix.com> wrote: > Thank you very much for the explanations, Josh. > > | the seekpoints are not the only places in the stream that can > | be seeked to, they are just hints about regular locations in > | the stream. you can still seek to any sample. the number of > | seekpoints are just one factor in determining how fast the >

Thank you very much for the explanations, Josh. | the seekpoints are not the only places in the stream that can | be seeked to, they are just hints about regular locations in | the stream. you can still seek to any sample. the number of | seekpoints are just one factor in determining how fast the | decoder can find any particular sample. I did a lot of testing | before deciding on -S10s. So

Thank you for the new release, Josh. I've downloaded it, but some of the details in the history file puzzle me, so I've not tried to use it yet. Pardon my denseness here ... First, as long as you don't use the --cuesheet option when you encode, are .flac files encoded by 1.1.0 still readable by earlier versions? Second, if the old default for seekpoints was -S100x and the new one is

Thank you Josh, the link clearly explains FLAC's philosophy and it souds quite logical: "For FLAC the intention is that applications can calculate the CDDB or CDindex ID from the CUESHEET block and look it up in an online or local database just like CD rippers and players do. But if you really want it in the file itself, the track metadata should be stored separate from the CUESHEET, and

Hello, I managed to insert cuepoints from a cue sheet and check them with metaflac. I witnessed that the FLAC headers then had additionnals sections (one for cuepoints and one for seekpoints), but i could not find documentation how the format used to store them (frame counts for both ?). Anyway it seems that cuepoints must be specified in MM:SS:fr format. It would be nice if those could be

--- On Mon, 4/20/09, porte64 at free.fr <porte64 at free.fr> wrote: > From: porte64 at free.fr <porte64 at free.fr> > Subject: [Flac] cuepoints: accuracy, titles and players > To: flac at xiph.org > Date: Monday, April 20, 2009, 10:07 AM > Hello, > > I managed to insert cuepoints from a cue sheet and > check them with metaflac. I witnessed that the FLAC >

For those who are interested in checking out my initial specification for the FlacPak format, I updated the web pages at: http://swami.sourceforge.net/flacpak.php The direct link to the specification notes: http://swami.sourceforge.net/flacpak_format.php For those who weren't reading the previous threads, FlacPak is a format being designed to handle compression of files containing binary and

Hi Neil, I think you have a misunderstanding or two. What you want to do does not require "code." In fact, you might want to move your question from the FLAC-Dev list to the FLAC (User) list. I'm on both lists, so I did not realize that you were basically asking in the wrong place. No "coding" skills whatsoever are required to create seekpoint markers in a

Hello, metaflac provides exporting CUEpoints, but not SEEKpoints. As i understand, cuepoints represent gaps beetween tracks (inserting pause), whereas seekpoints merely describe a list of seekable points. Can cuepoint be used just as seekpoints (in the end, the only thing which matters is that some classic media players will recognize them). In the script i have just posted before (joining