headers
Davy Durham | 12 Sep 03:48

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?
Permalink | Reply | 2 comments |
headers
Michael Pruett | 12 Sep 03:57

Re: audiofile -- endian issues

On Thu, Sep 11, 2003 at 08:48:58PM -0500, Davy Durham wrote:
> 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?

Davy, the byte order of the WAVE file format is always little-endian,
but the virtual byte order of any file is, by default, always the native
byte order of the system (big endian in your case).

Michael
Permalink | Reply | 1 comment |
headers
Davy Durham | 12 Sep 08:22

Re: audiofile -- endian issues

Michael Pruett wrote:

>Davy, the byte order of the WAVE file format is always little-endian,
>but the virtual byte order of any file is, by default, always the native
>byte order of the system (big endian in your case).
>  
>
Ah.. my bad.  Of the 4 places where byte order is concerned with 
(afSetByteOrder() and afSetVirtualByteOrder then x 2 for loading and 
saving) I was playing with the wrong setting.   Setting the virtual byte 
order is working beautifully.  (at least for .wavs which is what I'm 
testing currently)

Thanks,
  Davy
Permalink | Reply | 0 comments |
headers
Michael Pruett | 16 Sep 07:00

Re: afSeekFrames bug?

Jim,
I just added a regression test for seeking, and I have not encountered
any problems similar to the one you describe.

In order to investigate further, it would be helpful if you could provide
me with your test cases.

Michael

On Wed, Aug 20, 2003 at 10:04:26AM -0600, Jim Ramsay wrote:
> 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:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Pruett | 26 Sep 11:35

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
Permalink | Reply | 2 comments |
headers
Daniel Kobras | 28 Sep 10:37
Picon

Re: Audio File Library 0.2.4 released

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?

Regards,

Daniel.
Permalink | Reply | 1 comment |
headers
Michael Pruett | 29 Sep 02:45

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).

Michael
Permalink | Reply | 0 comments |
headers
Guido Draheim | 29 Sep 14:00
Picon
Picon

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;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Weisgerber | 29 Sep 14:40
Picon

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
Permalink | Reply | 1 comment |
headers
Michael Pruett | 30 Sep 03:05

Re: audiofile-0.2.4: test/seek.c nit

Christian, thanks for catching this omission.  I have fixed it in CVS.

Michael

On Mon, Sep 29, 2003 at 02:40:55PM +0200, Christian Weisgerber wrote:
> 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
Permalink | Reply | 0 comments |

Gmane