similar to: FLAC: how to dump seekpoints ?

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

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

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

It can but is probably not as nice as youwould like. flac -t *.flac if errorlevel 1 goto fail goto exit :fail echo Danger Will Robinson! Flac files failed integrity check. :exit For this reason cygwin and its bash for windows does a lot more. Notes on the batch file fragment above: if errorlevel 1 goto actually means if errorlevel 1 or greater so don't try if errorlevel 0 since it will

Hi Kerry, Thanks for the detailed information. I have seen some mp3 players that claim to play flac, so I think that this is not a problem any longer. My disk is formatted to FAT32 because in the past I tried to access it through some backwards Windows system and had to make sure it could be read by it. The only problem remains accessing the data through a USB connection, because the disk is

Hi Kerry, On 9/16/05, Kerry Hoath <kerry@gotss.net> wrote: > There is no standard for wav64 and a .wav in its standard form can only hold > 2gb of data. In this case the WAV files were less than 2 GB. > libsndfile can handle larger .wav files and so can other audio applications > but usually nonstandard subchunk data means that the wav reader in flac > can't understand

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

| yes, the exit code will be 1 if any of the flac files failed | testing, else 0 (i.e. if all of them passed). Thank you, Josh! Now the only trick is to see whether command.com can do anything with that information.

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

First, many thanks to Kerry Hoath (and some to a friend who is not on this list, but mostly to Kerry) for help with my batch file question. It's working, pretty much, but I'm still tweaking it, and I'll share the results when it's polished to my satisfaction. Related question: according to the longer help file, if you use the "verify" option during encoding, flac checks

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

In light of my experiences with that material and Josh's two most recent posts, I'll just stay away from encoding with either of those options and certainly from advising anyone else to use them. Thanks again to both Miroslav and Josh for their help with that question, and a long overdue thanks to Kerry Hoath for assistance with my batch file question some months back. I never shared

--- doc/html/documentation_tools_flac.html | 8 +++++--- doc/html/ru/documentation.html | 2 +- man/flac.1 | 6 ++++-- man/flac.sgml | 5 +++-- src/flac/main.c | 4 +++- 5 files changed, 16 insertions(+), 9 deletions(-) diff --git a/doc/html/documentation_tools_flac.html b/doc/html/documentation_tools_flac.html

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

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