Re: [flac-dev] The XMMS plugin

If anyone cares about this, they should let us know and help us figure out how to compile and test it on a current Debian or Ubuntu system. I still use this, though on Gentoo, not Debian or Ubuntu. It was removed from the Gentoo tree years ago, also, but still compiles and runs just fine if yo

[flac-dev] [PATCH] Fix a copy & paste error in a comment

>From 7d8d9a67d4ee598385e8e15a7388fae23af91428 Mon Sep 17 00:00:00 2001 From: Timothy B. Terriberry Date: Sat, 8 Dec 2012 12:42:57 -0800 Subject: [PATCH] Fix a copy & paste error in a comment. --- src/libFLAC/include/private/ogg_mapping.h |2 +- 1 files changed, 1 insertion

Re: [flac-dev] [PATCH] Various website edits

Erik de Castro Lopo wrote: > Is anyone working to keep that dshow filter up-to-date? Cristian Adam is the official maintainer. He is still around and responds to e-mail. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/

[flac-dev] [PATCH 1/4] xmms - Fix libtool usage

>From 9979edd1b6b6dd8c7c6bafaa68c9d974a8a77688 Mon Sep 17 00:00:00 2001 From: "Timothy B. Terriberry" Date: Thu, 7 Feb 2013 12:23:24 -0800 Subject: [PATCH 1/4] xmms - Fix libtool usage. 9b7cb22f removed the extra libtool-disable-static script in favor of always building with d

[flac-dev] [PATCH 2/4] xmms - include inttypes.h for PRIu64

>From b4dec97067239e547857fc13c4cd6903529baaef Mon Sep 17 00:00:00 2001 From: "Timothy B. Terriberry" Date: Thu, 7 Feb 2013 12:27:09 -0800 Subject: [PATCH 2/4] xmms - #include for PRIu64 Not sure where this was coming from before, but it's not getting included elsewher

[flac-dev] [PATCH 3/4] xmms - Fix inline linking problems with old glib

>From f392432e437c0ae7e3da2851e27ee3d997c3322c Mon Sep 17 00:00:00 2001 From: "Timothy B. Terriberry" Date: Thu, 7 Feb 2013 12:28:39 -0800 Subject: [PATCH 3/4] xmms - Fix inline linking problems with old glib f0296255 switched to --std=c99 by default, but old glib relies on the p

[flac-dev] [PATCH 4/4] Robustify autogen.sh

>From 05343cb10947c378d8a7678d4cd3cc3f442b3290 Mon Sep 17 00:00:00 2001 From: "Timothy B. Terriberry" Date: Thu, 7 Feb 2013 12:33:03 -0800 Subject: [PATCH 4/4] Robustify autogen.sh This allows the script to be run from somewhere other than the top-level build directory. --- au

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

Cristian Rodríguez wrote: >> sample sets. Each set of samples returns this error at a different location >> in >> the stream, but always the same location for the same file. >> >> or has many bytes that are close to the original. The bad frame's data is >> always >> the same, no matter how many t

Re: [flac-dev] 2GB limit patch

Erik de Castro Lopo wrote: > Err, thats a link to a post talking about flac's WAV reader being limited > to 4Gig files. Problem is, *all* WAV files greater than 4Gig are mal-formed. > Due to limitations in the way WAV files are specified, no valid WAV file > can ever be over 4Gig. And most don't w

Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4

Robert Kausch wrote: > The _lseeki64 patch probably is a little more controversial. The problem > is that fseeki64 and ftelli64 are not available in Windows XP - at least > not without installing extra MSVC runtime libraries. I changed compat.h > and replaced them with calls to _lseeki64, which was

Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4

with XP. So this wouldn't work anyway. Instead I've attached a patch that uses fgetpos/fsetpos. This is totally untested (I haven't even checked it compiles), but the idea should work. >From c24c5c8778221be7941d77a9b84c783a08021f00 Mon Sep 17 00:00:00 2001 From: "Timothy

Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4

Janne Hyvärinen wrote: > You people do realize these hacks would only be required for 10+ year > old obsolete compilers? No, they're required for easy distribution on 12 year old OSes (which, last I saw, make up almost 40% of Firefox's desktop userbase, and likely will continue to for some time)

Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4

Robert Kausch wrote: > MSDN says "The pos value is stored in an internal format and is intended > for use only by *fgetpos* and *fsetpos*." > (http://msdn.microsoft.com/en-us/library/70hdhh4t%28v=vs.80%29.aspx), so > I don't think it's a good idea to use it this way even if tests > suggested it wor

Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4

Robert Kausch wrote: > msvcrt.dll in the first place. The metadata object functions can be used > in a memory ownership transferring manner. Doing so will cause problems > when the calling EXE and the FLAC DLL use different CRTs as the DLL's Sigh, I thought we'd finally gotten rid of most of this

Re: [flac-dev] PATCH for cpu.c

Erik de Castro Lopo wrote: > Its crufty old code. I should be removed. It makes no sense to keep > supporting 20 year old compilers (MSVC6 was was released in 1989 and > MSVC7 in 1992 [0]). That's not quite accurate. MSC6 was released in 1989. MSVC was released in 1998. So only 15 years old :).

Re: [flac-dev] PATCH for cpu.c

Timothy B. Terriberry wrote: > That's not quite accurate. MSC6 was released in 1989. MSVC was released > in 1998. So only 15 years old :). *MSVC6, I meant. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] About de Bruijn sequences in bitmath.h

Ulrich Klauer wrote: > lvqcl wrote: > >> Found this code: ftp://ftp.samba.org/pub/unpacked/ntdb/lib/ccan/ilog/ilog.c > > The canonical location is at CCAN: http://ccodearchive.net/info/ilog.html > Note that the code is licensed LGPL. On the other hand, the author is > Xiph.org's Timothy Terryberry,

Re: [flac-dev] About de Bruijn sequences in bitmath.h

Timothy B. Terriberry wrote: > Uh, I thought Rusty and I relicensed that code public domain years ago. > I pinged him about updating the page. And FWIW, the page has now been updated. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xi

Re: [flac-dev] R128gain & metaflac

Ian Nartowicz wrote: > The Opus replaygain spec is fundamentally broken, so let's ignore that for > now. It is discussed ad nauseam elsewhere, but isn't going to change any time > soon. I haven't seen anyone make any concrete proposals for how it should change. Maybe I missed something. AFAIK,

Re: [flac-dev] R128gain & metaflac

Ian Nartowicz wrote: > It is certainly the biggest issue. Sure it should be simple to address, but > nobody seems willing to do so. The only response I've had so far is that the > output gain should *always* be applied, yet it *might* be an album gain. It > can't be both and there is no way to t

Re: [flac-dev] Undefined behaviour

Erik de Castro Lopo wrote: > has no performance impact on x86_64 linux, *may* not be the same with > other compilers. The approach we used in Opus was to use unsigned shifts: https://git.xiph.org/?p=opus.git;a=commitdiff;h=1ee139bca076 That relies on implementation-defined behavior, but not unde

Re: [flac-dev] [PATCH] "iff" instead of "if" in comments

lvqcl wrote: I noticed that there are several comments with "iff" word instead of "if", and it looks like typos to me. The patch is attached. "Iff" is commonly-used shorthand for the mathematical "if and only if", e.g., "returns true iff stat() succeeds for both files and they have the same d

Re: [flac-dev] [PATCH] "iff" instead of "if" in comments

lvqcl wrote: Wow. Didn't knew this. Congratulations. You're one of today's lucky 10,000: https://xkcd.com/1053/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [flac-dev] max size for album art?

lvqcl wrote: Scott Brown wrote: Is there any size limitation for album art? Slightly less than 16 megabytes. Not directly related to FLAC, but tangentially related, since FLAC is sometimes converted to Opus with tags imported, but as documented at the bottom of the page here:

Re: [flac-dev] Confusion about linear prediction within flac

Robin Patrick Decker wrote: I would really appriciate an explanation or information on a good resource to learn more about how the prediction coefficients are solved for. The Wikipedia page on this subject is not terrible: https://en.wikipedia.org/wiki/Linear_prediction The very high-level ans

Re: [flac-dev] Feedback on implementation of decoding of chained streams

brianw wrote: On Sep 1, 2024, at 12:44 PM, Martijn van Beurden wrote: Everything works, but as is with any change to the API, I don't know whether it is convenient for API users other than the flac command line tool. So, I'd like some feedback. I only looked briefly, but I had a few questions.

Re: [flac-dev] Feedback on implementation of decoding of chained streams

Martijn van Beurden wrote: Since chained streams can have different sample rates, how would one go about seeking to a specific _time_? I assume one would first use the sample rate of the first link to guess the sample number, seek to that point, correct if it turns out one of the links that pas

Re: [flac-dev] Feedback on implementation of decoding of chained streams

Martijn van Beurden wrote: As far as I know, please correct if wrong, neither libopusfile nor libvorbisfile provide this functionality either. In neither I could find a function to find the total number of samples over all links. Opus has a fixed samplerate so there is no changing, but libvorbisf

Re: [flac-dev] Feedback on implementation of decoding of chained streams

Martijn van Beurden wrote: There are still a lot of things that can be improved in libFLAC, so I think I'll leave it be for a while when this works. I agree it is not efficient, but for now, chained ogg is a niche use case for FLAC. I'd Incremental steps are usually best. I think mostly you wan

Re: [flac-dev] Feedback on implementation of decoding of chained streams

Martijn van Beurden wrote: Okay, I just came up with a possible solution. In the case of multiplexed streams, FLAC could not just keep track of its own serial number in that link, but also of the serial numbers of other streams in that link. That way, it could easily determine whether it is still