similar to: FLAC: how to dump seekpoints ?

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

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

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

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

Thank you all very much for making things clear. I had confused seekpoints and cuepoints indeed ! I propose that Kerry's definitions (below) be added to the documentation. regards, Phil ----- Mail d'origine ----- De: Kerry Hoath <kerry at gotss.net> ?: porte64 at free.fr Envoy?: Thu, 2 Apr 2009 11:28:04 +0200 (CEST) Objet: Re: [Flac] FLAC: how to dump seekpoints ? don't

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

Hello, Here's a script i use to join multiple PCM source files and feed them to FLAC. In the future i plan to add tag support from static CDDB (files). It would be nice if this feature could be incorporated to the native encoder. Another idea is to have flac/metaflac support joining FLAC files themselves (but this is much heavier to implement) -- and may pose issues with meta info like

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

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

Sorry for the somewhat off-topic post, but while we are on the subject of flac, here's my question: Is the current version of ogg flac (encoded with flac.exe from the official flac website) some kind of beta implementation or is it a fully compatible release that will continue to be supported by future applications? The reason I'm asking is because I get the following error message when

are internal structures, unexposed to the end-user as you suggest. For me, a seekpoint describes an offset in the audio file, and enables any player to jump to instantly jump to that position. For instance, if you pack up an a collection of audio tracks into a single FLAC file, there is a strong need for seeking ! It is common, typically in classical music, to have up to 40 tracks on a single CD

Hi List, Is there a way to correctly use the replay-gain feature on flac files that contain an entire album (i.e., multiple tracks with seekpoints added from a cue sheet)? -- Chris

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,

Hello, Apologies if this has already been covered. I'm trying to compile FLAC 1.2.0 under FreeBSD without ogg support: when I run gmake, I get: encode.c: In function `convert_to_seek_table_template': encode.c:2181: error: structure has no member named `use_ogg' the following appears to fix the problem for me, although I've not checked it fully: ---

Thank you very much! But how to deal with endianness in the case of bit stream? Some blocks (for example MinBlockSize) require 16bits (simply swap first and second), some block (e.g.MinFrameSize) require 3 byte-array to be reverted. Finally totalSamples is stored in 5 bytes ( only last 4 bits from first one byte are used). It was a real issue to make it little-endian (here is how I did it:

Ok, the patch from 2003 about improving seeking still didn't make it to CVS, so here is another try. I made some benchmarking with the test_seeking utility from flac sources to show how bad the current seeking is, especially without seektable. Track used for the experiment had about 50 minutes. In the following table is average number of seeks and number of decoded frames required for one

On Monday 11 February 2008 05:04:25 Pyt wrote: > Can you elaborate on what you mean by "correctly use" ? > > On Feb 11, 2008 1:03 AM, Christopher Brown <c-b@asu.edu> wrote: > > Is there a way to correctly use the replay-gain feature on flac files > > that contain an entire album (i.e., multiple tracks with seekpoints added > > from a > > cue sheet)?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The recent discussions about archiving CDs with flac prodded me to get abcde working again. I've filed a debian bug report with patches to the latest abcde that enable generating a toc file from the disc with cdrdao (rips CD-TEXT data and creates index points from subcode data). Combined with my patches to toc2cue, this is enough to rip even

First, Thank you for your answers. I using the following code to try simply decode a flac file and write the decoded data raw PCM file. The resulting file is just noise and pops, so is the decoded data in a different format than PCM? struct flacData { FILE *inputFile; FILE *outputFile; char *filename; }; FLAC__StreamDecoderReadStatus flac_DecoderReadCallback(const FLAC__StreamDecoder