similar to: feature request

Well, I'm quite frankly stumped. I'm writing a program that recurses into directories and reads (among others) FLAC files and should be able to read the vorbis comments ARTIST and TITLE from the file. A while back, I was popen()ing to metaflac, because I didn't want to mess with libFLAC. But now, it's the weekend, so I can mess around with this. Here's the code in question:

Thanks for the quick response on the C++ thing. It would also be nice if the host program could correctly write the STREAMINFO block in the stream encoder metadata callback without having to know the specifics of the header format (or worry about endianness). How exactly to achieve this might take some thought, but what about this idea: 1. The correct way to respond to the metadata callback:

This is a heads up to let you know of my plans to work on a senior thesis project dealing with editing Vorbis losslessly in Audacity. You can find more information about my plans and what I'm up to here: http://www.reverberate.org/computers/thesis/ "vcut" from vorbis-tools will be an excellent starting point for me. I notice that it's marked "experimental"; why is

Hello again. If you recall, I am the guy working on enabling Audacity to losslessly rearrange Ogg Vorbis files for my senior thesis. I have more or less completed the required modifications to Audacity to support this. You can read more about the work this entailed by reading my journal: http://www.reverberate.org/computers/thesis/journal Now my attention moves to the Ogg Vorbis code

On 2006-03-09 (Thu) ,at 23:20:50 Josh Coalson wrote: > the vorbiscomments are not in the streaminfo. you want to do: > > FLAC::Metadata::VorbisComment tags; > if (FLAC::Metadata::get_tags("somefile.flac", tags)) { > FLAC::Metadata::VorbisComment::Entry entry = > tags->get_comment(tags->get_num_comments-1); //e.g. last tag > // do something with

I am looking to losslessly archive a lot of music and share it over a network. The following stipulations lead me to an interesting conclusion: 1. Almost no programs can read or write flac files directly. 2. Almost all programs can read and write wav files directly. 3. The cost of encoding flac files is fairly low 4. The cost of decoding them is even lower 5. These files would be read much more

I'm trying to use libFLAC++ v1.1.2, to read Song information (like artist, trackname etc..). So.. I read metadata from file FLAC::Metadata::get_streaminfo("somefile.flac", infosik); and It's ok - no error, then I read vorbis info: FLAC::Metadata::VorbisComment vorbis_kom(infosik); int number_of_comments = vorbis_kom.get_num_comments(); and after that I have

Hi all, If I have code that does this: while (FLAC__stream_decoder_process_single (decoder)) /* Do something. */ ; I get an infinite loop. Shouldn't FLAC__stream_decoder_process_single return false if it gets to FLAC__STREAM_DECODER_END_OF_STREAM? If so, here's a patch. Cheers, Erik ------------------8<------------------8<------------------8<------------------

Matt Zimmerman <mdz@debian.org> wrote: > On Thu, Nov 21, 2002 at 08:11:13PM +0100, Steve Lhomme wrote: > > > Well, I think going GPL would be too much, only GPL softwares could use > > the library. > > This is a common misconception, but entirely untrue. There are many > free software licenses, including the BSD-style licenses, which are > compatible with the

On 09/09/2007, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > Daniel, > > A similar argument goes for the encoding quality description and digital rights. > > In contrast, the improved description of the content as in: artist, > band name, title, organisation involved, and people involved are > things that improve upon vorbiscomment and should probably be included

Yes, it's finally here. See the homepage for details, but here's a summary: - 10-15% decoder speedup - 24-bit input support restored - more robust plugins - new metadata block for Vorbis-style tags - vastly improved metadata editor - fixed bug with pipes and Windows - new libFLAC++, a C++ object wrapper around libFLAC - new metadata editing interface in libFLAC and libFLAC++ - and

What is the best way to add song metadata (artist, album, title, etc.) to flac files? I want to be able to define an arbitrary number of FIELD=value pairs. Earlier I heard someone mention using id3 tags. I tried this with the command-line "id3v2", and while it seemed to work I noticed that the resulting file no longer began with "fLaC", which violates the format

On 11/03/2016 05:28 AM, Phil Wyett wrote: > On Wed, 2016-11-02 at 21:37 -0700, Alice Wonder wrote: >> While doing a browser fingerprinting survey, I was quite surprised to >> see I actually have a FireFox plugin installed. >> >> The culprit is >> >> /usr/lib64/mozilla/plugins/librhythmbox-itms-detection-plugin.so >> >> It appears that whoever

Op wo 16 okt 2024 om 16:25 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > Yes, overwriting the streaminfo total_samples number is a bit of a hack, > but it would only affect those files with more than 2^36 samples that > contains the special seek point, so no difference for the average flac user. > > Not sure how the applications actually read flac files, if they

Thank you very much! But how to deal with endianness in the case of bit stream? Some blocks (for example MinBlockSize) require 16bits (simply swap first and second), some block (e.g.MinFrameSize) require 3 byte-array to be reverted. Finally totalSamples is stored in 5 bytes ( only last 4 bits from first one byte are used). It was a real issue to make it little-endian (here is how I did it:

On 02/15/15 22:48, Mark LaPierre wrote: > Hey Y'all, > > I though I would resurrect a long dead mail chain. > > I'm looking for a good replacement for Rhythmbox. I need a pod catcher > to catch podcasts and download them to my HD where I can then move them > onto my mp3 player that I take to work every day. > > I don't need a new mp3 player so don't

I'm writing a program that plays FLAC files using the libFLAC API's. Is there a specific way I'm supposed to handle multiple STREAMINFO metadata blocks? For example, should I ignore all but the first, or all but the last? The format spec doesn't mention anything. Thanks, - Brian Waters

I'm not sure about the legacy JIT interface, but I don't think this can be done cleanly with the current MCJIT interface. I mentioned a while ago that this is one of the improvements we'd like to make to MCJIT. I can definitely see Josh's point about performance, and so we won't want permissions to always be set, but I do think it's worth revising the interface between

I'm kind of swamped today so I'll answer what I can get away with until tonight: --- Joshua Haberman <joshua@haberman.com> wrote: > The most interesting questions to me are ones you didn't address: > > 1. Will Ogg FLAC become the default manifestation of the FLAC codec? > If not, why not? What does Ogg not offer that makes it worth having > two different file

It's certainly best to honor what the specification says. My assumption is that a "stream" could also be a continuous broadcast, not just a file. With a hypothetical server streaming FLAC bitstreams, I would assume that the most recent STREAMINFO is valid until another one comes along. If you're writing a file player, then perhaps you can trust the spec and assume