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

Am 15.10.24 um 19:03 schrieb Martijn van Beurden: > > No, seeking to a specific sample can take a while because of all the > back-and-forth, but seeking to almost the end of the file is very quick. > > I know this is not the cleanest way, but as this only for the rare cases Ah, I see, because the frame header also include either the sample number (variable frame size) or the frame

I think there is another major issue for me: In METADATA_BLOCK_STREAMINFO the field for the length is only 36 bit, that's not even half an hour at 40 MHz sample rate, resulting in that the encoder sets it to 0 for longer captures. In the seekpoint the sample number is 64 bit, which is more than enough. But how does the decoder handle the seektable when the total number of samples is unknown?

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

Op zo 13 okt 2024 om 22:33 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > Is the seektable written at the beginning of the file in the metadata > block or can there also be a second metadata block at the end? > Only at the start of the file. > > If it's at the beginning, would it possible to reserve space for N seek > points and during encoding remember

Op di 15 okt 2024 om 21:27 schreef Alistair Buxton <a.j.buxton at gmail.com>: > > I would like to see this kind of thing put into a secondary metadata block aimed specifically at SDR. This could be completely ignored by regular audio players - these files are not meant to be listened to anyway. I could probably figure out how to implement that, I even started looking into it once, but

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

Op di 15 okt. 2024 16:18 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > I see, but that would require changes in the software using libflac and > require the file to be easily seekable to be able to skip to the end and > depending on how far away the seek points are, it could take a while. > No, seeking to a specific sample can take a while because of all 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

Hi Martijn, Am 13.10.24 um 21:00 schrieb Martijn van Beurden: > > There's actually quite a lot of documentation for this. > > Please review https://xiph.org/flac/api/group__flac__stream__encoder.html#ga80d57f9069e354cbf1a15a3e3ad9ca78 > > I quote: >> SEEKTABLE blocks are handled specially. Since you will not know the >> values for the seek point stream offsets,

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,