One more thing... you will probably have to chmod +x flac-1.0.3_beta/test/test_streams.sh before doing the 'make check'. Here's a summary of the changes since 1.0.2: - decoder speedups (around 10-15%) - id3v1 support in winamp2 plugin - new vorbis comment metadata block - new metadata api - better metaflac (try 'metaflac --help') - libFLAC++ C++ wrapper around libFLAC - new -F option to flac to continue decoding through errors - fixed several bugs - flac with Windows pipes - ogg packet numbering and granulepos - several plugin bugs - several other minor ones; see sourceforge bug tracker Josh __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
On Tue, Jun 11, 2002 at 12:07:38AM -0700, Josh Coalson wrote:> 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.flac-1.0.3_beta compilation breaks for me with message: make[3]: Entering directory `/home/andrei/tmp/123/flac-1.0.3_beta/src/libFLAC' source='bitbuffer.c' object='bitbuffer.lo' libtool=yes \ depfile='.deps/bitbuffer.Plo' tmpdepfile='.deps/bitbuffer.TPlo' \ depmode=none /bin/sh ../../depcomp \ /bin/sh ../../libtool --mode=compile gcc -DPACKAGE=\"flac\" -DVERSION=\"1.0.3_beta\" -DHAVE_DLFCN_H=1 -DHAVE_GETOPT_LONG=1 -DFLAC__CPU_IA32=1 -DFLAC__ALIGN_MALLOC_DATA=1 -DFLAC__HAS_OGG=1 -DFLAC__HAS_NASM=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DSIZEOF_LONG_LONG=8 -I. -I. -I../.. -I./include -I../../include -g -O2 -O3 -DNDEBUG -fomit-frame-pointer -funroll-loops -finline-functions -Wall -W -Winline -DFLaC__INLINE=__inline__ -c -o bitbuffer.lo `test -f bitbuffer.c || echo './'`bitbuffer.c ../../depcomp: ../../depcomp: No such file or directory make[3]: *** [bitbuffer.lo] Error 127 -- andrei at tvcell d0t ru
Awesome, I'm psyched for 1.0.3.... the ID3v1 winamp2 support will be a neat addition, as is the faster decodes. Will 24-bit audio play nice with the final public version of 1.0.3? MW On Tue, 11 Jun 2002, Josh Coalson wrote:> One more thing... you will probably have to > > chmod +x flac-1.0.3_beta/test/test_streams.sh > > before doing the 'make check'. > > Here's a summary of the changes since 1.0.2: > > - decoder speedups (around 10-15%) > - id3v1 support in winamp2 plugin > - new vorbis comment metadata block > - new metadata api > - better metaflac (try 'metaflac --help') > - libFLAC++ C++ wrapper around libFLAC > - new -F option to flac to continue decoding through errors > - fixed several bugs > - flac with Windows pipes > - ogg packet numbering and granulepos > - several plugin bugs > - several other minor ones; see sourceforge bug tracker > > Josh > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Flac-dev mailing list > Flac-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flac-dev >
On Tue, 11 Jun 2002 11:51:33 +0400 Andrey Astafiev <andrei@tvcell.ru> wrote:> flac-1.0.3_beta compilation breaks for me with message:I had the same experience, too. I think that a cause is in configure and configure.in files. Therefore, let's rebuild these files. I took the following, and solved the problem. $ cd flac-1.0.3_beta $ automake $ autoconf $ ./configure ;make -- Daisuke Shimamura E-mail:Daisuke_Shimamura@nifty.com
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. 3. if you feel particularly helpful :) you can redo #2 with different options to configure (appropriate to your setup) e.g. --enable-debug --enable-sse --enable-3dnow The tests are quite exhaustive and will probably run a couple hours, depending on your system. If there are any problems, please report them back to this list. Also, package maintainers, it would be nice if you also did the whole autoconf process from scratch to see if there are any problems there. If you're so inclined you can poke around and try out some of the new stuff. Most of it is related to the new metadata interface and C++ API layer, but I have messed with the plugins a little so there are probably things to find there. The winamp3 plugin probably still does not work for recent version of wasabi. Thanks, Josh __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
Thanks, I see the problem. I'll try a fix tonight. Josh --- Daisuke Shimamura <Daisuke_Shimamura@nifty.com> wrote:> libxmms-flac-1.0.3 terminates xmms with a segmentation violation at > quitting time. > It happens only when quitting with no playing a flac file. > For example, quit after playing only mp3 files, just quit after > starting xmms. > But it doesn't happen after playing flac files. > I tried flac-1.0.2 plugin and a case of no flac plugin. This case was > OK. > > I attach the stack trace when terminating with SEGV. This is a just > quit > after starting. > > -------------------------------------- > $ gdb xmms > GNU gdb Red Hat Linux (5.1-1) > Copyright 2001 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-redhat-linux"... > (gdb) run > Starting program: /usr/bin/xmms > [New Thread 1024 (LWP 26534)] > [New Thread 2049 (LWP 26535)] > [New Thread 1026 (LWP 26536)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1024 (LWP 26534)] > __pthread_mutex_lock (mutex=0x66910) at mutex.c:99 > 99 mutex.c: No such file or directory. > in mutex.c > (gdb) where > #0 __pthread_mutex_lock (mutex=0x66910) at mutex.c:99 > #1 0x403b0fe8 in __libc_free (mem=0x40464e90) at malloc.c:3152 > #2 0x4120b175 in FLAC__bitbuffer_free (bb=0x81c1bd8) at > bitbuffer.c:340 > #3 0x4120accb in FLAC__bitbuffer_delete (bb=0x81c1bd8) at > bitbuffer.c:261 > #4 0x4121fa3b in FLAC__stream_decoder_delete (decoder=0x81c1ba8) > at stream_decoder.c:193 > #5 0x4121cc69 in FLAC__seekable_stream_decoder_delete > (decoder=0x81c1b88) > at seekable_stream_decoder.c:158 > #6 0x4120f759 in FLAC__file_decoder_delete (decoder=0x81c1b48) > at file_decoder.c:140 > #7 0x41140f26 in safe_decoder_delete_ (decoder=0x81c1b48) at > plugin.c:393 > #8 0x41140659 in FLAC_XMMS__cleanup () at plugin.c:216 > #9 0x0805f123 in cleanup_plugins () at pluginenum.c:417 > #10 0x0806be6c in mainwin_quit_cb () at main.c:904 > #11 0x08064a77 in pbutton_button_release_cb (widget=0x818c908, > event=0x820a870, button=0x818d280) at pbutton.c:71 > #12 0x0806466b in handle_release_cb (wlist=0x81297f8, > widget=0x818c908, > event=0x820a870) at widget.c:90 > #13 0x0806c5f4 in mainwin_release (widget=0x818c908, event=0x820a870, > > callback_data=0x0) at main.c:1146 > #14 0x40236aec in gtk_marshal_BOOL__POINTER () from > /usr/lib/libgtk-1.2.so.0 > #15 0x4026a436 in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0 > #16 0x4026976d in gtk_signal_real_emit () from > /usr/lib/libgtk-1.2.so.0 > #17 0x40267525 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0 > #18 0x402a1b89 in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0 > #19 0x40236a45 in gtk_propagate_event () from > /usr/lib/libgtk-1.2.so.0 > #20 0x40235a6f in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0 > #21 0x402e6d7f in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0 > #22 0x4031d773 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 > #23 0x4031dd39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 > #24 0x4031deec in g_main_run () from /usr/lib/libglib-1.2.so.0 > #25 0x40235333 in gtk_main () from /usr/lib/libgtk-1.2.so.0 > #26 0x08072dc9 in main (argc=1, argv=0xbffff9f4) at main.c:3516 > #27 0x4034c627 in __libc_start_main (main=0x80729a4 <main>, argc=1, > ubp_av=0xbffff9f4, init=0x80556b8 <_init>, fini=0x8084c50 > <_fini>, > rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xbffff9ec) > at ../sysdeps/generic/libc-start.c:129 > (gdb) > > -- > Daisuke Shimamura > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Flac-dev mailing list > Flac-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flac-dev__________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
I noticed that you bumped the library version for this release. In fact, you incremened it twice. FLAC 1.0.2 shipped with libFLAC.so.1, while 1.0.3beta seems to have libFLAC.so.3. It should never be necessary to increment the version more than once between releases; at first glance, I wonder whether you're trying to sync up the library version with the release version. This is usually not a good idea, and the libtool manual warns against it. So was this an intentional change? -- - mdz
* Josh Coalson (xflac@yahoo.com) wrote:> I have just released a source distribution which is the > candidate for the 1.0.3 release.1. Thanks for the VORBIS_COMMENT headers! 2. I was hoping that the new metadata API would mean that an encoder could be written without having to know *anything* about the bitwise layout of the stream format, but that seems not to be the case. From src/flac/encode.c: ( void metadata_callback() ) /* all this is based on intimate knowledge of the stream header * layout, but a change to the header format that would break this * would also break all streams encoded in the previous format. */ (massive bit-twiddling follows) As long as you're breaking API compatibility, why not fix this? 3. 'metadata --remove-vc-all' corrupts the target file if there is any VORBIS_COMMENT block present. 'metadata' can still read the file, but decoding errors out with FLAC__STREAM_DECODER_ERROR_LOST_SYNC. This seems to be permanent corruption: no further operations, including removing the VORBIS_COMMENT block, will restore it. Josh
The cc command line when building FLAC has gotten very long and unwieldy. Maybe it is time to use AC_CONFIG_HEADERS instead of passing everything in CFLAGS? -- - mdz
libxmms-flac-1.0.3 terminates xmms with a segmentation violation at
quitting time.
It happens only when quitting with no playing a flac file.
For example, quit after playing only mp3 files, just quit after
starting xmms.
But it doesn't happen after playing flac files.
I tried flac-1.0.2 plugin and a case of no flac plugin. This case was OK.
I attach the stack trace when terminating with SEGV. This is a just quit
after starting.
--------------------------------------
$ gdb xmms
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run
Starting program: /usr/bin/xmms
[New Thread 1024 (LWP 26534)]
[New Thread 2049 (LWP 26535)]
[New Thread 1026 (LWP 26536)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 26534)]
__pthread_mutex_lock (mutex=0x66910) at mutex.c:99
99 mutex.c: No such file or directory.
in mutex.c
(gdb) where
#0 __pthread_mutex_lock (mutex=0x66910) at mutex.c:99
#1 0x403b0fe8 in __libc_free (mem=0x40464e90) at malloc.c:3152
#2 0x4120b175 in FLAC__bitbuffer_free (bb=0x81c1bd8) at bitbuffer.c:340
#3 0x4120accb in FLAC__bitbuffer_delete (bb=0x81c1bd8) at bitbuffer.c:261
#4 0x4121fa3b in FLAC__stream_decoder_delete (decoder=0x81c1ba8)
at stream_decoder.c:193
#5 0x4121cc69 in FLAC__seekable_stream_decoder_delete (decoder=0x81c1b88)
at seekable_stream_decoder.c:158
#6 0x4120f759 in FLAC__file_decoder_delete (decoder=0x81c1b48)
at file_decoder.c:140
#7 0x41140f26 in safe_decoder_delete_ (decoder=0x81c1b48) at plugin.c:393
#8 0x41140659 in FLAC_XMMS__cleanup () at plugin.c:216
#9 0x0805f123 in cleanup_plugins () at pluginenum.c:417
#10 0x0806be6c in mainwin_quit_cb () at main.c:904
#11 0x08064a77 in pbutton_button_release_cb (widget=0x818c908,
event=0x820a870, button=0x818d280) at pbutton.c:71
#12 0x0806466b in handle_release_cb (wlist=0x81297f8, widget=0x818c908,
event=0x820a870) at widget.c:90
#13 0x0806c5f4 in mainwin_release (widget=0x818c908, event=0x820a870,
callback_data=0x0) at main.c:1146
#14 0x40236aec in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0
#15 0x4026a436 in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0
#16 0x4026976d in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#17 0x40267525 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#18 0x402a1b89 in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0
#19 0x40236a45 in gtk_propagate_event () from /usr/lib/libgtk-1.2.so.0
#20 0x40235a6f in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0
#21 0x402e6d7f in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0
#22 0x4031d773 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#23 0x4031dd39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#24 0x4031deec in g_main_run () from /usr/lib/libglib-1.2.so.0
#25 0x40235333 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#26 0x08072dc9 in main (argc=1, argv=0xbffff9f4) at main.c:3516
#27 0x4034c627 in __libc_start_main (main=0x80729a4 <main>, argc=1,
ubp_av=0xbffff9f4, init=0x80556b8 <_init>, fini=0x8084c50
<_fini>,
rtld_fini=0x4000dcc4 <_dl_fini>, stack_end=0xbffff9ec)
at ../sysdeps/generic/libc-start.c:129
(gdb)
--
Daisuke Shimamura
--- Matt Zimmerman <mdz@debian.org> wrote:> I noticed that you bumped the library version for this release. In > fact, > you incremened it twice. FLAC 1.0.2 shipped with libFLAC.so.1, while > 1.0.3beta seems to have libFLAC.so.3. It should never be necessary > to > increment the version more than once between releases; at first > glance, I > wonder whether you're trying to sync up the library version with the > release > version. This is usually not a good idea, and the libtool manual > warns > against it. > > So was this an intentional change?Hmm... -r 1.20 of src/libFLAC/Makefile.am (also tagged with RELEASE_1_0_2__2001-12-03) has: libFLAC_la_LDFLAGS = -version-info 2:1:1 I wasn't trying to sync up the lib version with the release version. But the API has changed enough to get a new major rev according to libtool conventions (it has all of new, changed, and deleted interfaces). Josh __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
--- Joshua Haberman <joshua@haberman.com> wrote:> 2. I was hoping that the new metadata API would mean that an encoder > could be written without having to know *anything* about the bitwise > layout of the stream format, but that seems not to be the case. From > src/flac/encode.c: > > ( void metadata_callback() ) > /* all this is based on intimate knowledge of the stream header > * layout, but a change to the header format that would break > this > * would also break all streams encoded in the previous format. > */ > > (massive bit-twiddling follows) > > As long as you're breaking API compatibility, why not fix this?I pushed this out to 1.0.4. I plan to add a FLAC__FileEncoder and on top of that a FLAC__WAVEEncoder or something like that.> 3. 'metadata --remove-vc-all' corrupts the target file if there is > any > VORBIS_COMMENT block present. 'metadata' can still read the file, > but > decoding errors out with FLAC__STREAM_DECODER_ERROR_LOST_SYNC. This > seems to be permanent corruption: no further operations, including > removing the VORBIS_COMMENT block, will restore it.I found this recently too. It is fixed in CVS. I am not sure whether I should do a 1.0.3_beta2 but I'll take suggestions. Josh __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com