[OT] ReZound-0.9.0beta Release

audiofile-0.2.4: test/seek.c nit

gcc only warns about this on 64-bit machines.

--- test/seek.c.orig	2003-09-29 14:36:01.000000000 +0200
+++ test/seek.c	2003-09-29 14:36:13.000000000 +0200
@@ -31,6 +31,7 @@

 #include <stdio.h>
 #include <stdlib.h>
+#include <string.h>

 #include <audiofile.h>

--

-- 
Christian "naddy" Weisgerber                          naddy <at> mips.inka.de

Re: Audio File Library 0.2.4 released

 > On Sun, Sep 28, 2003 at 10:37:56AM +0200, Daniel Kobras wrote:
 > > On Fri, Sep 26, 2003 at 04:35:36AM -0500, Michael Pruett wrote:
 > > > Version 0.2.4 includes the following changes:
 > > > * Added support for large files.  This option is disabled by
 > > >   default; to enable large file support, run configure with the flag
 > > >   --enable-largefile.
 > >
 > > As far as I can tell, a largefile-enabled libaudiofile is binary
 > > incompatible to a standard one on systems where off_t defaults to 32bit.
 > > Shouldn't the SONAME be bumped in this case to avoid havoc?
 >
 > Daniel, that is correct.  I have merely verified that the library works
 > with large file support enabled and have added the option only so that
 > those who wish to use the library in this configuration can easily compile
 > it themselves.  I expect that the standard Linux distributions will not
 > use this option as it would break binary compatibility (and because the
 > vast majority of libraries in use today do not support large files).
 >

Which is a bad situation since media files can be very long, and some of
the libaudiofile clients are compiled in largefile mode. If you want to
see, run the test program from http://ac-archive.sf.net/largefile which
tells of mismatches.

The binary incompatibility on 64on32 systems (mostly linux and solaris)
arises from direct usage of off_t in header files, instead of using a
64bit type directly for the filesizes. That's the situation in libaudiofile
as well, see  grep off_t audiofile.h
   typedef off_t AFframecount;
   typedef off_t AFfileoffset;

It is however possible to write up an interfaces that allows the library
to be compiled in largefile mode itself and to offer function call entries
for _both_ 32bit off_t and 64bit off_t code. It needs a bunch of #ifdefs
and re-#defines in the header and wrappers for 32bit call entries in the
source code.

Probably, making up a dualmode library is nothing that a programmer
learns in school, and hopefully the 64on32 thing will get lost at some
point anyway. In the meantime, I did test with zziplib that it is
indeed possible to write up dualmode support in a straightforward
manner, in libaudiofile it would touch
$ egrep "AFframecount|AFfileoffset" *.h | wc -l
      15
api calls that would require a duplicate call entry for the other mode.

In other words, a dualmode library does not need to be renamed at all,
since it is the library that can serve both 32bit off_t clients and
64bit off_t clients at the same time - while being itself compiled in
largefile mode. The most wellknown dualmode library is libc, building
on the largefile capabilities of the kernel, and interestingly it just
works 

cheers,
-- guido                                  http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)

Audio File Library 0.2.4 released

Version 0.2.4 of the Audio File Library is now available:
	http://www.68k.org/~michael/audiofile/
	http://oss.sgi.com/projects/audiofile/

Version 0.2.4 includes the following changes:
* Added support for large files.  This option is disabled by
  default; to enable large file support, run configure with the flag
  --enable-largefile.
* Improved support for markers in WAVE files.
* Added support for miscellaneous data in WAVE files.
* Cleaned up code and fixed a number of bugs.

This version has been tested on the following systems:
	mips-sgi-irix6.5 / IRIX 6.5 (MIPSpro cc 7.4m)
	i686-pc-linux-gnu / Debian GNU/Linux 3.0 (gcc 2.95.4)
	i686-pc-linux-gnu / Red Hat Linux 7.1 (gcc 2.96)
	sparc-sun-solaris2.8 / Solaris 8 (gcc 2.95.2)

I'd like to thank Davy Durham for his significant contributions to
this release.

Michael

audiofile -- endian issues

On a big-endian machine would I still need to swap endian when saving to
a .wav file.  I'm fairly sure that for the .wav format it is always assumed that the PCM is little
endian.  The lib won't accept anything but little endian for afInitByteOrder().  
And it doesn't seem to be doing any byte swapping on it's own
when writing a .wav on a big endian machine.

Is this the case for all the formats?

afSeekFrames bug?

Please be patient, this may take a moment to explain.

I am running this on a brand-new IBM machine running an old caldera linux
with a 2.2.16 kernel.  I cannot upgrade this kernel, I don't have any
control over the OS on this particular machine.  I downloaded and compiled
version 0.2.3 of the audiofile library using gcc 2.95.2, and it appears to
have gone smoothly.

I'm trying to use libaudiofile to obtain data from a WAV file and loop when
I get to the eof For testing purposes, I've created a series of wav files at
different bit resolutions, all with the same number of samples.  Let's take,
for example, one with 10 24-bit samples, ranging from 0x010203 through
0x01020c in sequence.

I open the wav file and get no errors.  The number of channels is 2, and I
set up my virtual sample format to be TWOSCOMP and 32-bit.

Then run a routine requesting 30 samples.  Basically, the code should be
have in this manner:

- Get 10 samples (5 frames) from the wav file, in order.  It does this
correctly.  I get:
  0x01020300
  0x01020400
  0x01020500
  0x01020600
  0x01020700
  0x01020800
  0x01020900
  0x01020a00
  0x01020b00
  0x01020c00
- Realize that EOF has been reached without reading all 30 samples and do
afSeekFrames( file, AF_DEFAULT_TRACK, 0 ).  It seems to do this correctly,
as afTellFrames returns 0 after the seek.
- Get 10 more samples (5 more frames) from the wav file, in order.  I expect
to get the same 10 I got last read.  Instead I get:
  0x01020800
  0x01020900
  0x01020a00
  0x01020b00
  0x01020c00
  0x00000000
  0x00000000
  0x00000000
  0x00000000
  0x00000000
  It appears that the seek only went back half-way in the file and started
reading at the 5th sample (half-way through the 3rd frame), reading 5 frames
(filling the not-found samples with 0), then realizing that the file only
had 5 frames (10 samples) in it, and returning.
- The next seek also apparently happens correctly, and afTellFrames returns
0.
- The next get returns 10 samples, all 0x00000000

I have tried replacing the call to afSeekFrames with closing and re-opening
the file, but there is no difference.  The second read still starts halfway
through the file.

Has anyone experienced this, or does anyone know how I can fix it?

Jim Ramsay

audiofile version 0.2.3 on Solaris

Not really a question but an information that may be helpful to few
users. I was able to successfully install the audiofile version 0.2.3
on SunOS 5.7 (Solaris 2.7) runing on x86 and sparc. However, I had to
download the autogen.sh from the current version in the source
tree. Without this step, the configuration step errors out because it
can't find ltconfig.

-Naveen

[PATCH] DLL support on cygwin

Hi,

I made a small patch to allow to build libaudiofile as DLL on Cygwin.

Changes: 
* configure.in: call AM_PROG_LIBTOOL after AC_PROG_CC.
* configure.in: call AC_LIBTOOL_WIN32_DLL.
* libaudiofile/Makefile.am (libaudiofile_la_LDFLAGS): add -no-undefined.

Hope this is of use/interest,

--
Masahiro Sakai

diff -urp audiofile-0.2.3.orig/configure.in audiofile-0.2.3/configure.in
--- audiofile-0.2.3.orig/configure.in	2001-10-26 13:10:41.000000000 +0900
+++ audiofile-0.2.3/configure.in	2003-04-15 22:32:14.000000000 +0900
@@ -20,12 +20,13 @@ VERSION=$AUDIOFILE_VERSION

 AM_INIT_AUTOMAKE($PACKAGE, $VERSION)
 AM_CONFIG_HEADER(config.h)
-AM_PROG_LIBTOOL

 dnl Checks for programs.
 AC_PROG_CC
 AC_PROG_INSTALL
 AC_PROG_MAKE_SET
+AC_LIBTOOL_WIN32_DLL
+AM_PROG_LIBTOOL

 dnl Checks for libraries.
 dnl Check for the ldexp function in the math library.
diff -urp audiofile-0.2.3.orig/libaudiofile/Makefile.am audiofile-0.2.3/libaudiofile/Makefile.am
--- audiofile-0.2.3.orig/libaudiofile/Makefile.am	2001-08-23 17:26:18.000000000 +0900
+++ audiofile-0.2.3/libaudiofile/Makefile.am	2003-04-15 22:32:38.000000000 +0900
@@ -23,7 +23,7 @@ libaudiofile_la_SOURCES = \

 libaudiofile_la_LIBADD = modules/libmodules.la

-libaudiofile_la_LDFLAGS = -version-info 0:2:0
+libaudiofile_la_LDFLAGS = -version-info 0:2:0 -no-undefined

 include_HEADERS = audiofile.h aupvlist.h af_vfs.h

audiofile on Solaris 9

Hello!
    Just thought you'd like to know, audiofile compiles fine on Solaris 
9 using the GNU C/C++ compiler v3.2.
------------------------------------------------------------------------------------------------------------------------------------------

11:00pm [ksh4250 at prague in /local/ksh4250/archives/audiofile-0.2.3] > 
gmake install
Making install in libaudiofile
gmake[1]: Entering directory 
`/local/ksh4250/archives/audiofile-0.2.3/libaudiofile'
Making install in modules
gmake[2]: Entering directory 
`/local/ksh4250/archives/audiofile-0.2.3/libaudiofile/modules'
gmake[3]: Entering directory 
`/local/ksh4250/archives/audiofile-0.2.3/libaudiofile/modules'
gmake[3]: Nothing to be done for `install-exec-am'.
gmake[3]: Nothing to be done for `install-data-am'.
gmake[3]: Leaving directory 
`/local/ksh4250/archives/audiofile-0.2.3/libaudiofile/modules'
gmake[2]: Leaving directory 
`/local/ksh4250/archives/audiofile-0.2.3/libaudiofile/modules'
gmake[2]: Entering directory 
`/local/ksh4250/archives/audiofile-0.2.3/libaudiofile'
gmake[3]: Entering directory 
`/local/ksh4250/archives/audiofile-0.2.3/libaudiofile'
/bin/sh ../mkinstalldirs /local/ksh4250/lib
 /bin/sh ../libtool --mode=install .././install-sh -c  libaudiofile.la 
/local/ksh4250/lib/libaudiofile.la
.././install-sh -c .libs/libaudiofile.so.0.0.2 
/local/ksh4250/lib/libaudiofile.so.0.0.2
(cd /local/ksh4250/lib && rm -f libaudiofile.so.0 && ln -s 
libaudiofile.so.0.0.2 libaudiofile.so.0)
(cd /local/ksh4250/lib && rm -f libaudiofile.so && ln -s 
libaudiofile.so.0.0.2 libaudiofile.so)
chmod +x /local/ksh4250/lib/libaudiofile.so.0.0.2
.././install-sh -c .libs/libaudiofile.lai /local/ksh4250/lib/libaudiofile.la
.././install-sh -c .libs/libaudiofile.a /local/ksh4250/lib/libaudiofile.a
ranlib /local/ksh4250/lib/libaudiofile.a
chmod 644 /local/ksh4250/lib/libaudiofile.a
----------------------------------------------------------------------
Libraries have been installed in:
   /local/ksh4250/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - use the `-RLIBDIR' linker flag

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
/bin/sh ../mkinstalldirs /local/ksh4250/include
 .././install-sh -c -m 644 audiofile.h /local/ksh4250/include/audiofile.h
 .././install-sh -c -m 644 aupvlist.h /local/ksh4250/include/aupvlist.h
 .././install-sh -c -m 644 af_vfs.h /local/ksh4250/include/af_vfs.h
gmake[3]: Leaving directory 
`/local/ksh4250/archives/audiofile-0.2.3/libaudiofile'
gmake[2]: Leaving directory 
`/local/ksh4250/archives/audiofile-0.2.3/libaudiofile'
gmake[1]: Leaving directory 
`/local/ksh4250/archives/audiofile-0.2.3/libaudiofile'
Making install in sfcommands
gmake[1]: Entering directory 
`/local/ksh4250/archives/audiofile-0.2.3/sfcommands'
gmake[2]: Entering directory 
`/local/ksh4250/archives/audiofile-0.2.3/sfcommands'
/bin/sh ../mkinstalldirs /local/ksh4250/bin
  /bin/sh ../libtool --mode=install .././install-sh -c sfconvert 
/local/ksh4250/bin/sfconvert
.././install-sh -c .libs/sfconvert /local/ksh4250/bin/sfconvert
  /bin/sh ../libtool --mode=install .././install-sh -c sfinfo 
/local/ksh4250/bin/sfinfo
.././install-sh -c .libs/sfinfo /local/ksh4250/bin/sfinfo
gmake[2]: Nothing to be done for `install-data-am'.
gmake[2]: Leaving directory 
`/local/ksh4250/archives/audiofile-0.2.3/sfcommands'
gmake[1]: Leaving directory 
`/local/ksh4250/archives/audiofile-0.2.3/sfcommands'
Making install in test
gmake[1]: Entering directory `/local/ksh4250/archives/audiofile-0.2.3/test'
gmake[2]: Entering directory `/local/ksh4250/archives/audiofile-0.2.3/test'
gmake[2]: Nothing to be done for `install-exec-am'.
gmake[2]: Nothing to be done for `install-data-am'.
gmake[2]: Leaving directory `/local/ksh4250/archives/audiofile-0.2.3/test'
gmake[1]: Leaving directory `/local/ksh4250/archives/audiofile-0.2.3/test'
Making install in docs
gmake[1]: Entering directory `/local/ksh4250/archives/audiofile-0.2.3/docs'
gmake[2]: Entering directory `/local/ksh4250/archives/audiofile-0.2.3/docs'
gmake[2]: Nothing to be done for `install-exec-am'.
gmake[2]: Nothing to be done for `install-data-am'.
gmake[2]: Leaving directory `/local/ksh4250/archives/audiofile-0.2.3/docs'
gmake[1]: Leaving directory `/local/ksh4250/archives/audiofile-0.2.3/docs'
gmake[1]: Entering directory `/local/ksh4250/archives/audiofile-0.2.3'
gmake[2]: Entering directory `/local/ksh4250/archives/audiofile-0.2.3'
/bin/sh ./mkinstalldirs /local/ksh4250/bin
 ./install-sh -c audiofile-config /local/ksh4250/bin/audiofile-config
/bin/sh ./mkinstalldirs /local/ksh4250/share/aclocal
mkdir /local/ksh4250/share
mkdir /local/ksh4250/share/aclocal
 ./install-sh -c -m 644 audiofile.m4 
/local/ksh4250/share/aclocal/audiofile.m4
/bin/sh ./mkinstalldirs /local/ksh4250/lib/pkgconfig
mkdir /local/ksh4250/lib/pkgconfig
 ./install-sh -c -m 644 audiofile.pc 
/local/ksh4250/lib/pkgconfig/audiofile.pc
gmake[2]: Leaving directory `/local/ksh4250/archives/audiofile-0.2.3'
gmake[1]: Leaving directory `/local/ksh4250/archives/audiofile-0.2.3'
------------------------------------------------------------------------------------------------------------------------------------------

-- 
Some Food For Thought:
**********************************************************************
Life Sucks.  Cynical, misanthropic male, 34, looking for soul mate but
certain not to find her.  Drop me a note.  I'll call you, we'll talk and
I'll ask you out to dinner where I'll probably spend more than I can
afford in a feeble attempt to impress you.  Then we'll realize we have
absolutely nothing in common and we'll go our separate ways, more
embittered and depressed than before (if such a thing is possible).
**********************************************************************

-------------------------------------------
Kieran S. Hagzan
System Administrator's Group
Department of Computer Science - Building 70
Rochester Institute of Technology
Rochester, New York, USA 14623-5608
E-Mail:  mailTo:ksh4250 <at> hagzan.homelinux.org
WWW:     http://hagzan.homelinux.org
-------------------------------------------

libaudiofile not largefile sensitive

Through a discussion on alt.os.linux.mandrake, I had to notice
that every library has a risk of being broken when using the
system off_t type in its exported interfaces, including
structures and function synopsis.

The point comes from the fact that systems like linux and
solaris are "largefile sensitive" - a -D_LARGEFILE_SOURCE
will shift the "off_t" type from being a 32bit entity into
a 64bit entity. This will make for a nice and pretty
callframe mismatch.

Grepping a bit through header files installed on my system
it occurs to me that audiofile.h contains quite a lot of
these off_t arguments in its api calls - it can be only by
luck that no application had the misfortune to trap on one
of these, doesn't it.

A autoconf'ed lib 'centric treatment of the topic is given in:
http://article.gmane.org/gmane.comp.sysutils.autoconf.general/1893

Given the number of affected calls in this lib, it might be
the  best trick to just #error out as soon as a largefile
compile -Ddef will be seen. It's not the best thing, right.

cheers,
-- guido                                 http://ac-archive.sf.net

ATRAC3

Hi Michael et al,

Thanks for libaudiofile.  It is very good software which I use daily and
I hope you continue to support it for some time! :)

Anyway, I am interested in adding in support for ATRAC3-encoded files. 
Whilst the format is not terribly well defined by open specifications, I
understand that it's possible to use Sony's MS Windows codec to do the
actual work and have a wrapper around this in libaudiofile.  How
difficult is this, and can anyone provide a pointer to how to go about
this?

All the best,
Pete
--

-- 
Pete Ryland
http://pdr.cx/