similar to: 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. How does FLAC__stream_decoder_get_total_samples() work for

For some reason, I didn't get Brians email, but I noticed it was replied to, so I'll copy from the archive > Is there an overview - in plain English - summarizing the API changes? No, not yet, as it isn't final yet. However, for the API changes, one only has to look at the header files, not the actual source files. > Without diving in to the source changes, my first question

I've been thinking a while about this, reading some code, and I can't get my head around it, so I hope I can get some more help and/or advice. As an example, take a multiplexed, chained stream, with both links being a video stream alongside a FLAC audio track. To find the end of the first link and/or beginning of the second link, we opportunistically seek forward, ending up in the second

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 in the current link, as any page will either have a known or unknown serial number. Is that also how opusfile works? I can't

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 want to avoid painting yourself into a corner API-wise. I haven't thought

There's an entry in the changelog: "Improved decoding efficiency of all bit depths but especially so for 24 bits (lvqcl)" A couple of comments: 1) The patch that improves encoding for all depths was proposed by Miroslav Lichvar <http://git.xiph.org/?p=flac.git;a=commit;h=4eab6313cd2198b5647d925bdb3847590505fa21> 2) "Performance checks" graph posted by Martijn van

Hi all, Currently I'm looking for users of the --keep-foreign-metadata feature of FLAC. There has been some improvement of this feature in FLAC 1.4.0. Since 2007 there has been a warning in FLAC that --keep-foreign-metadata is a new feature. I think removal of this warning is long overdue, but there are still some issues surrounding it. So, if there are users of this feature on the mailing

Can you please wrap the setvbuf in _WIN32 IFDEFs too? Currently memory usage of FLAC decoding is about 1MB, so this patch is increasing memory usage tenfold, also for platforms that do not need this. It is a non-problem on my system anyway. Op 26-09-14 om 10:36 schreef Janne Hyv?rinen: > I made some changes to the previous patch. I don't know why I > originally didn't put the

Sorry, I am newbie. Sample codes are from https://github.com/oneman/libflac/tree/master/examples/cpp. I used FLAC__stream_decoder_process_single function but it still gives exception. Maybe I could not control read callback, you're right. I will check it and write result in this thread. Thanks for help. 2013/7/1 Martijn van Beurden <mvanb1 at gmail.com> > I'll top-post this

Hi, I am developing an audio network system and using boost, OpenAL and FLAC library in C/C++. I can stream raw audio data over network but I want to encode audio before streaming in current PC and decode after streaming in other PC because of bandwidth limit. I run your sample codes, encode.c and decode.c, about file encode / decode. Then, I run streaming encode / decode with two different

Hi, Martijn, Thank you for reaching out, and apologies for late reply It is a dedicated metadata for volume normalization on our player. Please kindly refer to our company information here: https://labelgate.com/ application ID: SONN application name: Sony Normalizer contact e-mail address: taku.kurosawa at labelgate.com<mailto:taku.kurosawa at labelgate.com> Taku From: flac-dev

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 next to proceed?? Apparently this is my first time here, so appreciate any advice assistance. Best regards, Taku From: Kurosawa, Taku Sent: Thursday, November 22, 2018 8:41 PM To: 'Martijn van Beurden'

Thanks for the help Martijn, I get the same FLAC__STREAM_DECODER_END_OF_STREAM error after doing the 2 steps you suggested. Scott On Mon, May 19, 2014 at 9:36 AM, Martijn van Beurden <mvanb1 at gmail.com>wrote: > Once more hi, > > I've tried to reproduce this issue, but I am unable to do so. Could you > try to re-encode the file with FLAC (to make sure it is not an

On 26-05-13 14:20, Martijn van Beurden wrote: > On 26-05-13 11:33, Erik de Castro Lopo wrote: >> Hi all, >> >> In my latest commit I have updated all version strings and copyright >> dates. > > Here are two patches for the website, updating the copyright as well > and copying the changelog. I would like to propose copying the > contents of flac-website.git

Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > but I'd rather see the real seeking bug fixed instead I think I might have a fix, but it touches quite a bit of code, so it'll take some time. I think the problem is that because bogus headers might pop up in the stream of which the CRC checks out, the whole frame is decoded to validate that a frame is correct. The bogus header

ERROR while decoding data state = FLAC__STREAM_DECODER_END_OF_STREAM It's happening with every file that I've tried now, using both 1.2.1 and 1.3.0. If a file has artwork and I remove padding, I get the above error when verifying or decompressing. If no artwork and I remove padding, the file verifies and decompresses with no issues. I'm writing tags via

Hi FLAC developers, This is Saki, a student from Australian National University currently working on FLAC decoding with GPU acceleration. I am now facing a problem of locating the FLAC frame header. I am now trying to find a way to find the nearest frame header after a specific byte. I have already filtered the invalid data, check the CRC-8 at the end of file. But I am still finding some

Hi, This patch improves compression a very tiny bit on average, but up to 0.1 percentage point for classical music. I haven't found any tracks that show worsening compression with this patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-LPC-order-guess.patch Type: text/x-patch Size: 0 bytes Desc: not available Url :

Yes, this is such a case. However, implementing this in a future encoder/decoder would break compatibility with most (likely all) existing decoders, and only in some very, very rare cases where the material is such that the encoder chooses to use negative shifts, which makes it even harder to troubleshoot. Furthermore, as this can only be used in very rare cases, there is no benefit from allowing

On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > >> but I'd rather see the real seeking bug fixed instead > > > > I think I might have a fix [...] So the problem is that FLAC__stream_decoder_process_single returns error before it finds a