Displaying 20 results from an estimated 20000 matches similar to: "Should FLAC join Xiph?"
2004 Sep 10
4
Should FLAC join Xiph?
En r?ponse ? earldunovant@earthlink.net:
> On 21 Nov 2002 at 1:39, Josh Coalson wrote:
>
> > 2. The core libraries would become BSD-licensed. I've been really
> > 50/50 on this ever since I submitted the question to Slashdot
> > (see http://ask.slashdot.org/article.pl?sid=01/11/27/1650256 ).
>
> Interesting thead. I think your issues are with software
2004 Sep 10
2
FLAC joins Xiph
It's official:
http://xiph.org/ogg/flac.html
It's OK to keep submitting patches but I'm going to hold off
on integrating anything until CVS is moved over. Note that
codec code (libFLAC, libFLAC++, libOggFLAC, libOggFLAC++) will
be covered under Xiph's BSD-like license from here on out.
Josh
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus -
2004 Sep 10
2
Should FLAC join Xiph?
--- Joshua Haberman <joshua@haberman.com> wrote:
> * Josh Coalson (xflac@yahoo.com) wrote:
> > 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:
> > >
> > >
2004 Sep 10
2
Should FLAC join Xiph?
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
2004 Sep 10
0
Should FLAC join Xiph?
Josh Coalson <xflac@yahoo.com> wrote:
> That is the question I put before you all tonight :)
>
> (Short background, Xiph is the corp behind Vorbis and Ogg,
> among other things; see http://xiph.org/about.html . I
> think Emmett is here now so correct any of this if it's
> wrong.)
>
> I've been talking a little with Emmett Plant and Monty about
> this.
2004 Sep 10
0
Should FLAC join Xiph?
On Thu, Nov 21, 2002 at 01:39:40AM -0800, Josh Coalson wrote:
> 1. FLAC would benefit from the increased visibility from the association.
> Emmett can probably expound more upon this point. Anyway, hopefully this
> will mean it's popularity will rise, not just with users but also with
> developers of other tools.
I agree that a relationship with Xiph.org would have a positive
2004 Sep 10
3
Should FLAC join Xiph?
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
2004 Sep 10
2
adding song metadata
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
2004 Sep 10
2
xmms-flac plugin in OS X - Apple X11
I have been using Apple's X11 on OS X and I got the source and compiled
flac 1.0.5 beta2. Everything seemed to build and install OK, but the
xmms-flac plugin is not working, and I cannot open xmms. I get the
following error when I launch xmms from xterm:
brian it's 8:41pm, what now? xmms &
[1] 567
brian it's 8:41pm, what now? dyld: xmms Undefined symbols:
2004 Sep 10
11
flac-1.0.3_beta released
I have just released a source distribution which is the
candidate for the 1.0.3 release. At this time I would
ask anyone who is willing to help test it to do the
following:
1. download the tarball and unzip it:
http://prdownloads.sourceforge.net/flac/flac-1.0.3_beta-src.tar.gz?download
2. do
./configure && make && make check
This will build all code and run all the tests.
2004 Sep 10
3
reading vorbis comments with FLAC++?
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:
2004 Sep 10
2
Serious bug in FLAC
As far as I can tell I've found a serious bug in the command line
flac encoder :(
I have created many hundreds of flac files and I was very annoyed to
discover that the XMMS flac plug-in had intolerably long seek times,
but since that had been mentioned on this list a bunch of times
without anyone actually investigating, I thought I had better actually
find the BUG which causes this.
1. I
2004 Sep 10
3
flac in the filesystem?
Hi Matt, thanks for the reply.
* Matt Zimmerman (mdz@debian.org) wrote:
> On Tue, Oct 30, 2001 at 11:39:11PM -0800, Joshua Haberman wrote:
>
> > So I was wondering if flac could be incorporated into the filesystem
> > driver so that any file ending in .wav would be transparently encoded
> > into flac. I don't know if this could be done at the vfs level so that
>
2004 Sep 10
2
ACM for FLAC.
Josh Coalson wrote:
> --- engdev <engdev@ozemail.com.au> wrote:
>
>>Hi,
>>
>>Has there been any progress on the ACM for FLAC
>>that was being looked at by Steve Lhomme?
>
>
> Haven't heard anything here about it for a long time.
Sorry, I sent my reply to engdev privately (because there's no good
reply to). In short I haven't worked on
2004 Sep 10
2
UCI Project Announcement
Greetings all.. I'm sending this message out here because I suspect that some
folks involved in this project might be interested in the following. If this
is not the case (or this is not an appropriate forum for this sort of thing) I
apologize in advance..
Project Announcement and Call for Participation
-----------------------------------------------
The
2004 Sep 10
3
FLAC support in Phatbox car audio system
For the interested, the Phatbox (a car audio system) now has
firmware to support FLAC files. I have a news bullet on the
FLAC site:
http://flac.sourceforge.net/news.html#20020213
This is the first hardware support for FLAC (more is coming)
and I think the first support of any non-proprietary lossless
audio format for any hardware. Kudos to Phatnoise for taking
the lead.
Josh
2004 Sep 10
2
stream_encoder metadata callback
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:
2004 Sep 10
1
xmms-flac plugin in OS X - Apple X11
On Friday, January 24, 2003, at 12:28 AM, Josh Coalson wrote:
> --- Brian Haberman <habesct@mac.com> wrote:
>> I have been using Apple's X11 on OS X and I got the source and
>> compiled
>> flac 1.0.5 beta2. Everything seemed to build and install OK, but the
>>
>> xmms-flac plugin is not working, and I cannot open xmms. I get the
>> following
2004 Sep 10
1
make headers C++ compatible?
Hello FLACers,
I'm working on implementing FLAC support for Audacity, a cross-platform
audio editor (audacity.sourceforge.net). We're experimenting with using
FLAC as the internal data representation.
Unfortunately, the FLAC headers cannot be used in C++ programs because of
the use of 'private' and 'protected' as variable names in
stream_decoder.h, stream_encoder.h, and
2007 Sep 07
6
Re: multiple core support
it actually is complicated. the libFLAC api is not suited to a
multithreaded design because the i/o is stream-based, not file-
based. flac(.exe) is the file-based wrapper around libFLAC that
allows it to work on files. the way libFLAC buffers data is also
impossible to parallelize without significantly changing the api.
it would take a specialty file-based encoder using an independent
frame