Subject: bin/10380: audiorecord puts bogus encoding info in file header
To: None <gnats-bugs@gnats.netbsd.org>
From: None <eramore@era-t.ericsson.se>
List: netbsd-bugs
Date: 06/16/2000 14:26:12
>Number:         10380
>Category:       bin
>Synopsis:       audiorecord puts bogus encoding info in file header
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 16 14:27:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Michael Eriksson
>Release:        -current as of about May 31, 2000
>Organization:
Ericsson Radio Systems AB
>Environment:
System: NetBSD kafka 1.4Z NetBSD 1.4Z (KAFKA) #0: Wed May 31 23:43:12 CEST 2000 mer@kafka:/usr/src/sys/arch/i386/compile/KAFKA i386


>Description:

audiorecord puts a "Sun/NeXT" audio header at the beginning of its
output files. When it sets the encoding field in the header, it uses
the encoding value of NetBSD's audio interface, as defined in
/usr/include/sys/audioio.h. Sun/NeXT headers use a completely other
set of encoding values, as defined in usr.bin/audio/common/libaudio.h.

By chance, the default encoding (ulaw) happens to have the same value
(1) in both encoding domains, but many of the possible audio formats
can't even be described by the Sun/NeXT audio file header.

>How-To-Repeat:

Record audio in another format than ulaw and check the file's header.

>Fix:

Don't use the Sun/NeXT audio file format, or at least not by default.
What file format to use instead is not known by me, but no header (raw
format) is obviously much better than a bogus header...

If the Sun/NeXT format is kept (as default or as an option), the
program should create a correct header or complain that it's
impossible.
>Release-Note:
>Audit-Trail:
>Unformatted: