Re: [flac-dev] 64-bit residuals

functions be used? ... I ask because my use of FLAC is entirely 24-bit, so I appreciate the discovery of this potential issue. Brian Willoughby On Mar 24, 2022, at 09:05, Martijn van Beurden wrote: > Hi all, > > I just filed an issue on github: > https://github.com/xiph/flac/iss

Re: [flac-dev] Two questions

On Aug 9, 2021, at 11:31, Martijn van Beurden wrote: > Op zo 8 aug. 2021 06:24 schreef Federico Miyara : >> As I wanted to stop at sample Nend, I used Nend + 1, instead, to ensure that >> the sample Nend is the last one. > > Considering Nend, did the count start at 0 or at 1? The flac utility

Re: [flac-dev] Two questions

On Aug 4, 2021, at 00:10, Federico Miyara wrote: > Brian, > > Once more, thanks for taking your time to answer my questions and provide > interestig insights. Some comments below. > >> I recommend writing your own utility based on the FLAC library, in C, with >> the features you want. I do

Re: [flac-dev] Two questions

hen one value is zero. If you find a pattern that indicates a bug, even just with the documentation, then please report it. Maybe you can fix it, or maybe someone else can. Brian Willoughby ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Two questions

On Aug 2, 2021, at 08:40, Federico Miyara wrote: > 1) Is there a way to get the audio size (number of samples) and other > information, such as number of channels, from a flac file without fully > decoding it? Yes. There is a specific header with this information. Look for the

Re: [flac-dev] Autocorrelation precision insufficient

Thanks. I should probably start a new subject, but I have related questions. Please don't feel obligated to answer ... I'm just curious. 1) What would affect the ability of an embedded FLAC firmware to decode certain files? Is it possible that the SD702 is not capable of processing complex

Re: [flac-dev] Autocorrelation precision insufficient

- but the decoder remains compatible. Witness MP3, where they improved the algorithm of the encoder and produced smaller files, all without requiring an update to the decoder. I'm assuming that FLAC fits that same model. Brian Willoughby On Jun 25, 2021, at 14:15, Robert Kausch wrote: > I concur with Da

Re: [flac-dev] FLAC specification clarification

the warning that they risk incompatibility by deviating from the reference implementation. I own devices with FLAC implemented in firmware that is quite different from the reference implementation. I wouldn't want to edit the specification to narrow it to fit those devices, either. Brian Willoughby

Re: [flac-dev] identical audio but not identical unrecognized chunks

e. Logic Pro will automatically add the waveform image to a file that's been freshly restored from a flac backup. Brian Willoughby ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] FLAC frame boundaries and protocol

samples like 24-bit audio. I remember being interested in streaming, as opposed to file-based compression, but I can’t recall whether I ever finished that project. Brian Willoughby On Mar 5, 2019, at 10:36 AM, Dave Harris wrote: > Hello, > > I've set up and have been reading th

Re: [flac-dev] New ID registration

be performing any such tests? Brian Willoughby On Dec 11, 2018, at 3:05 AM, Kurosawa, Taku wrote: > Hi Martjn, and everyone, > > Apologies if I have missed the reply, but I think I have not got any comment > so far on this. That means our new ID request is accepted? What should I do >

Re: [flac-dev] [PATCH 0/7] PowerPC64 performance improvements

On Jul 11, 2018, at 5:59 PM, Anton Blanchard wrote: > Hi Brian, > >> Thank you for this collection of patches. >> >> How can I test them? What platforms (computers) have the ppc64 or >> POWER9 processor? > > The IBM Bounty Source page has a list of resources: > >

Re: [flac-dev] [PATCH 0/7] PowerPC64 performance improvements

Thank you for this collection of patches. How can I test them? What platforms (computers) have the ppc64 or POWER9 processor? Brian On Jul 10, 2018, at 2:31 PM, Anton Blanchard wrote: > > The following series adds initial vector support for PowerPC64. > On POWER9, flac --best is about 3.3x

Re: [flac-dev] [bug] --keep-foreign-metadata discards WAV cue markers

used it this way, but often wondered whether the extra option was necessary. Apparently, it is. Hope this helps, Brian Willoughby On May 11, 2018, at 5:21 PM, Nouvelle Collection <nouvellecollect...@gmail.com> wrote: > Hello, > I noticed that option --keep-foreign-metadata disc

Re: [flac-dev] libFLAC optimizations request

but I don't have the code at home. > I will create a patch with my changes for review. > > Regards, > Gabriel > > On Sun, Feb 4, 2018 at 9:57 AM, Brian Willoughby <bri...@audiobanshee.com> > wrote: >> Correction, the flac command-line does create a 40-byte Vorbis

Re: [flac-dev] libFLAC optimizations request

the standard library, then you should be able to create a solution without modifying libFLAC. Brian On Feb 4, 2018, at 12:43 AM, Brian Willoughby <bri...@audiobanshee.com> wrote: > Gabriel, > > metadata_has_vorbis_comment is a FLAC__bool which defaults to false. There > s

Re: [flac-dev] libFLAC optimizations request

Gabriel, metadata_has_vorbis_comment is a FLAC__bool which defaults to false. There should be no reason to modify stream_encoder.c, but just modify the caller. The following command: metaflac —remove —block-type=VORBIS_COMMENT —don’t-use-padding … will remove Vorbis comments from existing

Re: [flac-dev] using libflac++ on a live internet stream

On Dec 13, 2017, at 8:12 AM, Chris Barrett <cbarrett.c...@gmail.com> wrote: > Thanks Brian. I converted everything to libFLAC and got the same results. > > [snip] > > I can send out some of the code fragments if needed. > > Thanks, > Chris > > On Tue, Dec 1

Re: [flac-dev] using libflac++ on a live internet stream

Hi Chris, Have you tried the Standard C libflac option? Not that I have anything against the C++ flavor, but I've only ever worked with the C API, to keep things simple. Sorry for the brief response, but I wanted to reply quickly. Brian On Dec 12, 2017, at 1:51 PM, Chris Barrett

Re: [flac-dev] FLAC compression experiment

dy quieter. It doesn't work losslessly if you artificially reduce the volume - because then you're losing information. Brian Willoughby On Aug 19, 2017, at 2:37 PM, z1x2c3v4z1x2c3v4 <z1x2c3v4z1x2c...@hotmail.com> wrote: > I feel I have found a super high compression way of FLAC. I have

Re: [flac-dev] [Cellar] FLAC Markdown

or both of the C language FLAC or C++ language FLAC++ libraries. I think that's the advantage you're looking for. The FLAC libraries have been ported to all major operating systems as well as many embedded platforms, so this C language is quite prevalent. Brian Willoughby Sound Consulting On Jun

Re: [flac-dev] warning that legacy WAVE file has format type 1 but bits-per-sample is 24

it seems like it would be prudent to add a command line option to preserve the existing behavior, just in case anyone has archived their audio using FLAC and would need to maintain compatibility with the legacy WAVE format. It's not always possible to replace certain old programs, especi

Re: [flac-dev] [PATCH 2/5] SIMD: remove extra space

I agree with Erik regarding this patch. On Feb 19, 2017, at 12:17 PM, Erik de Castro Lopo wrote: > lvqcl wrote: >> Most libFLAC code don't have a space between if and a parenthesis, >> so the patch removes them from lpc_intrin_sseNN.c files. > > I don't really agree with

Re: [flac-dev] Flac multi channel

"FLAC" users are actually working with FLAC in Ogg container files. Brian Willoughby On Jan 27, 2017, at 12:55 AM, Olivier Tristan <o.tris...@uvi.net> wrote: > Thanks everybody for their answer. > > This is quite unfortunate for me, but hey, that's life. > > I

Re: [flac-dev] Flac multi channel

like FLAC in Ogg is the choice (but I have not experimented with this option, personally). Brian Willoughby Sound Consulting On Jan 25, 2017, at 11:27 AM, Olivier Tristan <o.tris...@uvi.net> wrote: > I see :( > > That what I would call a good struct size optimisation. &

Re: [flac-dev] Do we need a pre-release?

g point for someone who needs a plain makefile. > Even if slightly broken, it should be kept as a template. > Dave Maybe add a README.lite in that directory, or a section in an existing README, to explain the purpose of Makefile.lite and the fact that it may not work exact

Re: [flac-dev] test_streams dependencies

My assumption is that the code was written to call flac_fopen() so that it is portable to every operating system, even those without fopen(). If you replace flac_fopen() with fopen(), then the tests won't compile on systems that don't have fopen(). You could simply have the following: #if

Re: [flac-dev] question about src/test_seeking.c - seek_barrage()

Agreed. Although there wasn't a universal standard when FLAC was started, it sure seems like int64_t and related types are available on all systems these days. Either FLAC__intXX or intXX_t are better than the old types, like byte, word, dword, quadword, or whatever. Brian On Jan 31, 2016,

Re: [flac-dev] FLAC__BYTES_PER_WORD==8 test results

On Dec 30, 2015, at 3:09 AM, Thomas Zander wrote: > On 29 December 2015 at 21:50, lvqcl wrote: >> So, does it make sense to #define FLAC__BYTES_PER_WORD (in bitreader.c) >> as 4 for 32-bit and as 8 for 64-bit targets? > > Your tests so far

Re: [flac-dev] How to check for 64-bit CPU?

It seems that most compilers define some sort of architecture values, but they're not necessarily consistent across all compilers. I believe that the original point of the FLAC__CPU_X86_64 and similar defines was to make these consistent within the FLAC sources, but not to reinvent the wheel

Re: [flac-dev] flac-dev Digest, Vol 131, Issue 8

Trojan Horse software? Running on a list-member's computer? I deleted the message already, but the headers might have some clues. I'm not too worried unless it happens again. Brian On Oct 24, 2015, at 12:16 PM, Marcus Johnson wrote: > How the hell did this spam

Re: [flac-dev] Supporting 32 bit data

there is an extremely compelling reason. A minor headache is that the FRAME_HEADER does not support 32-bit sample sizes on its short list, but there is an option to defer to the STREAMINFO for sample size. That might pose a challenge for 32-bit files. Not sure yet. Brian Willoughby Sound C

Re: [flac-dev] config.rpath?

On Aug 1, 2015, at 7:50 PM, Dave Yeo dave.r@gmail.com wrote: On 08/01/15 12:55 AM, Erik de Castro Lopo wrote: I've just switched autogen.sh from bash to sh and made sure it works with /bin/bash Plus symlinks are unwanted. I've also added a --no-symlinks option to autogen.sh. Happy

[flac-dev] Apple afconvert SRC (was: FLAC implementation in Windows 10)

Sorry for the non-FLAC content, but I will say that a utility like afconvert that also supported FLAC would be great. It would be very useful to be able to convert directly from a FLAC that is very large to a CAF, since the latter can exceed 4 GB without breaking the format. On Jul 19, 2015,

Re: [flac-dev] FLAC implementation in Windows 10

On Jul 14, 2015, at 8:18 AM, Declan Kelly flac-...@groov.ie wrote: On Mon, Jul 13, 2015 at 01:28:22PM +0200, mva...@gmail.com wrote: FLAC is not the only one though, Apple Lossless has been added to the mix in the same way, but (properly) creates smaller files. Can anyone on the list

Re: [flac-dev] [PATCH] Fix for odd RIFF size

specification on this subject, and to share my experience with common RIFF writer/reader bugs. Brian Willoughby On Jul 9, 2015, at 2:28 PM, lvqcl lvqcl.m...@gmail.com wrote: This patch should fix ticket https://sourceforge.net/p/flac/bugs/419/ and its duplicate https://sourceforge.net/p/flac

Re: [flac-dev] num_comments==0 and comments==0

is there, but when you build the fully optimized version the assert will be removed anyway. Seems safer to leave the FLAC_ASSERT() and then work to make sure the tests cover the potential memory leaks as well as ensure that fully-optimized release builds turn off all assert() macros. Brian Willoughby Sound

Re: [flac-dev] keep qlp coeff precision such that only 32-bit math is required

to see why the change came about. Brian Willoughby Sound Consulting On Apr 18, 2015, at 12:20 PM, Brian Willoughby bri...@audiobanshee.com wrote: Hmm, I don't know the history of the code, but flac 1.2.1 stream_encoder.c has

Re: [flac-dev] flac (encoder, analyzer, decoder) tool now (also) available in JavaScript‏

If there is a problem with running out of memory, decoding a file in whole will surely run into problems. I have FLAC files that are hours long, so mobile devices would surely run out of memory. In contrast, a streaming player would be able to play any size file. You were also concerned about

Re: [flac-dev] [PATCH] for flac/decode.c

allowed the header to be preserved for either WAV or AIFF. I'm not sure what was implemented, though, and I have not tested whether abnormal WAV headers are preserved. If --keep-foreign-metadata is not used, then nothing is preserved from the original WAV except the audio. Brian Willoughby

Re: [flac-dev] WAVEFORMATEX/TENSIBLE

On Dec 14, 2014, at 5:23 PM, lvqcl lvqcl.m...@gmail.com wrote: Brian Willoughby wrote: Currently the header of a decoded WAV file can be different to the original WAV file because FLAC doesn't preserve 'fmt ' chunk. For example: create a 24-bit stereo .wav file with WAVEFORMATEXTENSIBLE

Re: [flac-dev] [PATCH] for flac/decode.c

On Dec 14, 2014, at 1:14 AM, Erik de Castro Lopo mle...@mega-nerd.com wrote: lvqcl wrote: Also, I have a question. Currently flac complains about 24-bit .wav files if they have old WAVEFORMATEX header and not 'proper' WAVEFORMATEXTENSIBLE header. However it writes such files itself. Is

Re: [flac-dev] [PATCH] Improve LPC order guess

area to enhance performance in another area. Are these the sorts of things that can be handled by expanding the compression options, rather than thwarting existing performance? Brian Willoughby ___ flac-dev mailing list flac-dev@xiph.org http

Re: [flac-dev] [PATCH] Improve LPC order guess

Thank you for the explanation, Martijn! On Dec 3, 2014, at 9:38 AM, Martijn van Beurden mva...@gmail.com wrote: Op 03-12-14 om 18:14 schreef Brian Willoughby: I would like to point out that 'quiet' material is common when making original recordings. This is probably a misunderstanding: I

Re: [flac-dev] Two new CVEs against FLAC

On Nov 25, 2014, at 8:27 AM, Declan Kelly flac-...@groov.ie wrote: On Tue, Nov 25, 2014 at 12:29:33AM -0800, mle...@mega-nerd.com wrote: CVE-2014-9028 : Heap buffer write overflow CVE-2014-8962 : Heap buffer read overflow Is it known what other FLAC decoding software or firmware

Re: [flac-dev] Two new CVEs against FLAC

On Nov 26, 2014, at 1:40 AM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Brian Willoughby wrote: While we're on the topic, what sort of consequences are there, really, with this vulnerability? Worst case, your player stops playing on a file that cannot be played anyway. Yes, it's bad

Re: [flac-dev] New release

purely for security, the next with new changes in other areas. Brian Willoughby On Nov 24, 2014, at 12:47 AM, Miroslav Lichvar mlich...@redhat.com wrote: On Sun, Nov 23, 2014 at 02:44:00AM -0800, Erik de Castro Lopo wrote: lvqcl wrote: I have a couple of questions: 1) Do you plan

Re: [flac-dev] Compression failed message

(and equally lossless). However, I agree that it is rather strange to return non-zero by default, requiring a command-line option to defeat. I would expect it to be the reverse: off by default, and enabling non-zero on larger files via command-line option. Brian Willoughby Sound Consulting

Re: [flac-dev] Compression failed message

contacting the developers. Brian Willoughby ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] Exact FLAC subset constraints

Yep, that looks conclusive. Thanks for finding this. Brian On Jan 12, 2014, at 11:08, lvqcl wrote: Also found this: http://lists.xiph.org/pipermail/flac-dev/2008-May/002550.html http://lists.xiph.org/pipermail/flac-dev/2008-May/002559.html ___

Re: [flac-dev] Exact FLAC subset constraints

I think you've found a bug, Bart. flac 1.2.1 did not have any FLAC__format_blocksize_is_subset() function, so the source you're seeing in format.c must be new. If the format documentation you linked to is correct, then either the specifications are self-contradictory, or the code is not

Re: [flac-dev] PATCH for rice_parameter calculation

Or, I was originally thinking: rice_parameter = 0; k = partition_samples; if (k mean) { int n = mean - k; rice_parameter += n; k = n; } (sorry for the hasty post) On Oct 11, 2013, at 10:34, Brian Willoughby wrote: Hmm

Re: [flac-dev] What is in directory flac.pbproj?

Erik's request to simply delete the .pbproj directory and its contents. Brian Willoughby Sound Consulting p.s. Unfortunately, I do not know who originally created those .pbproj files, why they did it, or whether they ever worked. You might even find archived list messages where I asked about

Re: [flac-dev] Patch to add Unicode filename support for win32 flac

On Mar 17, 2013, at 03:57, LRN wrote: /me looks at chmod and utime wrappers: Ah, i knew i've missed something! :) Also, i didn't consider wildcards (i thought shell was supposed to handle them...). I believe that shell does handle wildcards on all Unix variants, including OSX. Since

Re: [flac-dev] Higher compression modes from Flake

On Mar 14, 2013, at 13:24, Declan Kelly wrote: I want the tightest possible compression, while remaining 100% compatible with the subset that all known FLAC decoders can successfully stream or play now in cars, Hi-Fi units, MP3 players and cell phones. The out and out most widely

Re: [flac-dev] Higher compression modes from Flake

of options that are already available in the official flac command-line, albeit without a short, numerical abbreviation. Brian Willoughby Sound Consulting On Mar 13, 2013, at 02:49, Marko Uibo wrote: Is it planned someday to implement additional higher (9-12) compression modes like in Flake

Re: [flac-dev] I reinstalled OS X, now FLAC 1.3 git won't compile.

When you reinstalled OSX, did you also reinstall the developer tools? I often forget that extra step. I assume you did, otherwise you wouldn't have gcc or make, but I figure it's worth asking. Also, there are option Unix tools that usually aren't installed unless you ask for them. Brian

Re: [flac-dev] [flac 1.3.0pre2 pre-release] Updates to test suite

, but not both at the same time. Maybe the patches to the tests should wait until 1.3.1 Brian Willoughby Sound Consulting ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] 2GB limit patch

is the proper format for files that exceed 4 GB, while standard RIFF/WAVE should allow reading of files up to 4 GB. For maximum compatibility, writing WAV files over 2 GB should be avoided whenever possible, since so many tools used signed 32-bit file sizes. Brian Willoughby Sound Consulting

Re: [flac-dev] 2GB limit patch

would only need to change if the FLAC file size limits were altered. Besides, I believe that FLAC is supposed to be a stream with no maximum size limit. No API changes should be necessary for the command-line FLAC to support 4 GB WAV files. Did I miss something? Brian Willoughby Sound

Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio

tools use float without lossy conversion. The only requirement there is that synthesized data should avoid +1.0 sample values unless clipping is acceptable or scaling is added before conversion. Brian Willoughby Sound Consulting ___ flac-dev mailing

Re: [flac-dev] Commonly getting FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA on valid audio

not be used or allowed anywhere in libFLAC. Brian Willoughby Sound Consulting On Feb 9, 2013, at 12:50, Erik de Castro Lopo wrote: Secondly, the scaling can be switched off don't you? See: http://www.mega-nerd.com/libsndfile/ command.html#SFC_SET_NORM_DOUBLE

Re: [flac-dev] Tag flac as flac 1.2.1_git

On Jan 21, 2013, at 22:57, Erik de Castro Lopo wrote: IMO, any code change at all, even just whitespace is worthy of its own version number. If the md5sum of the source code tarball is different it warrants an updated version number. Why would you release a new version of FLAC if the binary

Re: [flac-dev] Define 6.1 and 7.1 channel mappings

On Jan 17, 2013, at 21:41, Ralph Giles wrote: On 13-01-17 7:26 PM, Brian Willoughby wrote: I vote for documenting the --channel-map option in the --help Do you ever use --channel-map yourself, or recommend it to clients? Professional surround mastering is delivered on very specific media

Re: [flac-dev] Tag flac as flac 1.2.1_git

. Brian Willoughby Sound Consulting On Jan 17, 2013, at 09:27, Ralph Giles wrote: On 13-01-16 11:10 PM, Erik de Castro Lopo wrote: My understanding is that the recent changes for 7 and 8 channels was a documentation change only. I think we should also change the flac front-end utility

Re: [flac-dev] Tag flac as flac 1.2.1_git

The amount of time that has passed since the last change has nothing to do with the version number. I'm inclined to believe that 1.2.2 would be appropriate. I'm sure there will be other, more appropriate ways to celebrate the new release after the long period of stability. Brian Willoughby

Re: [flac-dev] Tag flac as flac 1.2.1_git

On Jan 12, 2013, at 14:28, Martijn van Beurden wrote: On 12-01-13 22:46, Brian Willoughby wrote: I would suggest that everyone keep in mind the vast installed base of hardware FLAC recorders and players, and not senselessly make them obsolete without extremely compelling reasons. This can

Re: [flac-dev] Bug or strange behaviour or --output-prefix

is given. I often process *.flac in large directories.) For the second example, --create-output-directories would allow you to use any of the examples you gave without having flac stop with an error when the output directory structure does not already exist. Brian Willoughby Sound Consulting

Re: [flac-dev] Git branch with compiling fixes for win32

improve its results, but keep in mind that changes to compilers sometimes produce less optimal results for particular cases, even if they involve improvements in most general cases. But it's certainly good to double-check periodically as compilers improve. Brian Willoughby Sound Consulting

Re: [flac-dev] FLAC QUESTION

an answer for you here, but perhaps you can continue to work on your code and find the problem. Brian Willoughby Sound Consulting ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] [PATCH] Fix buffer overflow in metaflac

Agreed. I was going to suggest memcpy() or something equivalent, because the FLAC structure is not literally a C string, but rather a 32-bit field that may or may not have a terminating NULL. Erik's code should work correctly in all cases. On Apr 5, 2012, at 04:02, Erik de Castro Lopo

Re: [flac-dev] Compiling flac for OSX 10.4

everything you need. If there are any problems with this build (and nobody has complained to me since 2009), then please let me know so I can make corrections and update the installer. Brian Willoughby Sound Consulting On Feb 9, 2012, at 22:44, Glenn McCord wrote: I've been trying

Re: [Flac-dev] Bug: end-of-line in FLAC console output

It's becoming clear to me that we need to distinguish between the different aspects of FLAC software, whether it be the core library, command-line, or third-party tools. Although I use the command-line tool exclusively (plus a few of my own tools), I really don't care about bugs there or

Re: [Flac-dev] A-law and mu-law

beyond what it is already. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Git branch with compiling fixes for win32

What bugs? On Nov 18, 2011, at 04:16, Bastiaan Timmer wrote: It's good to see some updates to the FLAC project after so much time! Will there be any timeline for a bugfix-release? ___ Flac-dev mailing list Flac-dev@xiph.org

Re: [Flac-dev] Git branch with compiling fixes for win32

, then it would be great to see those contributed to the open source collection. However, none of those items would really result in a change to the FLAC library sources, which have been stable and solid for a respectable amount of time. Brian Willoughby Sound Consulting

Re: [Flac-dev] MD5 Signature Mismatch

On Jun 1, 2011, at 05:12, Scott C. Brown 02 wrote: He sent me a link to the files here: http://www.archive.org/details/wolf2011-05-29.cleantone There are no uncompressed files here, so it's difficult to discover what you need to know. I just grabbed the first track (only 2.7 MB), and

Re: [Flac-dev] MD5 Signature Mismatch

On Jun 1, 2011, at 19:15, Scott C. Brown 02 wrote: I thought it might be an uploading problem, but he also gets the same issues when simply moving from one of his computers to the other. (I supposed that could also be a transfer issue, though I doubt it). He's using a 3rd party front

Re: [Flac-dev] MD5 Signature Mismatch

Signature even exists in these files before continuing to determine the reason for the mismatch. Maybe someone else has more information. Brian Willoughby Sound Consulting On May 31, 2011, at 19:20, Scott C. Brown 02 wrote: I found an old thread from 2007: http://www.mail-archive.com

Re: [Flac-dev] Can a libFLAC encoder be initialize and called from inside a libFLAC decoder callback?

. Brian Willoughby Sound Consulting On May 24, 2011, at 10:16, David Troendle wrote: I am getting large, corrupted native FLAC files when trying to call the encoder from inside the decoder. The metadata in the output file is OK. Is initializing and calling an encoder from inside a libFLAC

Re: [Flac-dev] Can a libFLAC encoder be initialize and called from inside a libFLAC decoder callback?

two processes instead of being limited to two threads within a process. The pipe could also allow you to decode on one machine and encode on another over a network connection - assuming that's of any use to you. Brian Willoughby Sound Consulting

Re: [Flac-dev] Variable Bit Rate

rate and a guarantee that nothing will be lost when you reduce bit rate below uncompressed. Masklinn actually did a great job of explaining why, I just wanted to present a different way of looking at the problem. Brian Willoughby Sound Consulting

Re: [Flac-dev] Variable Bit Rate

is impossible. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Variable Bit Rate

, but the order should certainly be preserved in whatever buffer is used. The streaming software could be as simple as decoding to a WAV file and then starting playback after a sufficient amount of data has been collected. Brian Willoughby Sound Consulting

Re: [Flac-dev] Variable Bit Rate

a difference, then something is wrong with your system, not with the FLAC format. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] 24 bit flac decoding efficiency

and measure the amount of time spent in each function, hopefully providing you with a weighted list so that you can start optimizing the top candidate right away and then go from there. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev

Re: [Flac-dev] Support for CAF in flac command-line?

On Mar 7, 2011, at 08:46, Paul Davis wrote: On Mon, Mar 7, 2011 at 11:25 AM, Brian Willoughby bri...@sounds.wa.com wrote: All professional tools use conversion factors such as 0x8000 for float-to-int and int-to-float because it has a single significant bit, and thus this factor does

[Flac-dev] FLAC__stream_decoder_skip_single_frame() // how is it used?

situation. I'm certainly planning to read the format and API documentation thoroughly. Brian Willoughby Sound Consulting P.S. My desired application is to take so-called 'hidden' tracks from a CD and split them into two files by dropping the silence in between. It's fairly common to have

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

delay between my HDTV set tuner and computer USB tuner, since each has a different amount of buffering in its pipeline, exacerbated by the digital audio system. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http

Re: [Flac-dev] Idea to possibly improve flac?

format, and thus I doubt there would be any professional interest in changing things just for the sake of change or newness. Brian Willoughby Sound Consultinf On Jan 7, 2011, at 12:56, David Richards wrote: Its really sad to hear thats happening but even more sad is the fact that flac is becoming

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

there probably isn't enough silence to handle it that seldom. But a fraction of a second between tracks several times per hour would never be noticed, unless there is a continuous audio broadcast with absolutely no silence. Brian Willoughby Sound Consulting

Re: [Flac-dev] Idea to possibly improve flac?

! Keep us posted with your findings! Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

On Jan 7, 2011, at 17:18, Paul Davis wrote: On Fri, Jan 7, 2011 at 7:36 PM, Brian Willoughby bri...@sounds.wa.com wrote: I'd like to borrow these ideas, or at least similarly-inspired ideas, and have FLAC streaming designed such that the stream can tell the playback software when to reset

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

and OggFLAC should not have any real problems due to compression of silent frames. Any place there is a problem should be blamed on bad streaming client / player code, not on the format itself. Brian Willoughby Sound Consulting ___ Flac-dev mailing list

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

of the picture? i.e., what about just using pure FLAC and IP? Brian Willoughby Sound Consulting On Jan 7, 2011, at 20:49, David Richards wrote: The actual non made up number for 44100 is 23 seconds. :D 4096 samples, 254 packets in an ogg page. ___ Flac-dev

Re: [Flac-dev] Cue sheets/Tagging question

a --seekpoint= marker for each track. Sometimes you really need to take the time to read everything available to you, especially when you have been waiting for months for someone else to read it to you. Brian Willoughby Sound Consulting On Nov 11, 2010, at 01:44, Neil Wilkes wrote: I still

Re: [Flac-dev] Cue sheets/Tagging question

On Nov 10, 2010, at 12:14, Neil Wilkes wrote: Is it possible to place track markers that will be reflected in a cue sheet within a long FLAC file? I have a label who want to offer FLAC downloads of complete albums - but there have to be track points designated within the FLAC file How

Re: [Flac-dev] Bugfix release?

to stereo FLAC, simplifying my archival process. Brian Willoughby Sound Consulting On Jul 22, 2010, at 23:33, grarpamp wrote: Hi. It has been some time since I posted to the list, and may be some time in the future until I have an oppurtunity to revisit FLAC. So, as I have been quite satisfied

Re: [Flac-dev] Compiling in Xcode

, but ran out of time. Brian Willoughby Sound Consulting On Jul 21, 2010, at 06:46, Dmitry Kichenko wrote: On 2010-07-21, at 2:24 AM, Brian Willoughby bri...@sounds.wa.com wrote: The flac sources are distributed in a configuration that is designed primarily for building from the command-line

Re: [Flac-dev] Compiling in Xcode

package that is available via links at flac.sourceforge.net Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

  1   2   >