Re: Some topics

[Erik Jarvi <ejarvi megsinet net>]

On Wed, Oct 04, 2000 at 12:23:11PM -0500, Dan Mueth wrote:
> 
> On 4 Oct 2000, Tommaso Bianchi wrote:
> 
> > Hello to everyone, 
> > 
> > I want to discuss some topics with you in order to keep my mind clear
> > from the beginning. I really need some feedback.  
> > 
> > 1. Sound license: legal considerations.
> > Do sounds need a license,like GPL? Can I download a "free" sound file
> > from the Net and include it into Gnome without being cited? 
> 
> I think they really need to be both copyrighted and licensed.  In fact, if
> we don't know who the copyright belongs to, then you can't really trust
> the license IMO.  With sounds being passed around the net, one generally
> doesn't know either of these accurately.  This is why I'd like to see the
> copyright and license info as metadata inside the sound file if possible -
> so it doesn't get lost.  This would generally have to be stored as a
> "comment".  I'm not sure which audio formats support comments
> though.  Does anybody know?

I've just been looking into this.  RIFF and AIFF (.wav and .aif) file formats
support meta data.  These being the most popular. One way would be to put the
license in as a Cue point. (Some times known as a Marker.) 

It looks like you can store strings in the headers of a .wav file. I've been
reading the RIFF specs. Yikes!

from the specs:


Storing Strings in RIFF Chunks


     This section lists methods for storing text strings in
     RIFF chunks. While these guidelines may not make sense
     for all applications, you should follow these
     conventions if you must make an arbitrary decision
     regarding string storage.RIFF chunk;text strings in

     NULL-Terminated String (ZSTR) FormatZSTR format, in
     RIFF chunk


     A NULL-terminated string (ZSTR) consists of a series of
     characters followed by a terminating NULL character.
     The ZSTR is better than a simple character sequence
     (STR) because many programs are easier to write if
     strings are NULL-terminated. ZSTR is preferred to a
     string with a size prefix (BSTR or WSTR) because the
     size of the string is already available as the <ckSize>
     value, minus one for the terminating NULL
     character.WSTR format, in RIFF chunkBSTR format, in
     RIFF chunk
     String Table FormatString table format, in RIFF chunk


     In a string table, all strings used in a structure are
     stored at the end of the structure in packed format.
     The structure includes fields that specify the offsets
     from the beginning of the string table to the
     individual strings. An example follows:

      typedef struct
      {
          INT    iWidgetNumber;    // the widget number
          WORD offszWidgetName;  // an offset to a string in
      <rgchStrTab>
          WORD offszWidgetDesc;  // an offset to a string in
      <rgchStrTab>
          INT    iQuantity;      // how many widgets
          CHAR rgchStrTab[1];    // string table (allocate
      as large as needed)
      }   WIDGET;

     If multiple chunks within the file need to reference
     variable-length strings, you can store the strings in a
     single chunk that acts as a string table. The chunks
     that refer to the strings contain offsets relative to
     the beginning of the data part of the string table
     chunk.

     NULL-Terminated, Byte Size Prefix String (BZSTR)
     SeriesBZSTR format, in RIFF chunk


     In a BZSTR series, a series of strings is stored in
     packed format. Each string is a BZSTR, with a byte size
     prefix and a NULL terminator. This format retains the
     ease-of-use characteristics of the ZSTR while providing
     the string size, allowing the application to quickly
     skip unneeded strings.

     Multiline String Format


     When storing multiline strings, separate lines with a
     carriage return/line feed pair (ASCII 13/ASCII 10
     pair). Although applications vary in their requirements
     for new line symbols (carriage return only, line feed
     only, or both), it is generally easier to strip out
     extra characters than to insert extra ones. Inserting
     characters might require reallocating memory blocks or
     pre-scanning the chunk before allocating memory for
     it.Multiline string format, in RIFF chunk

     Choosing a Storage Method


     The following lists guidelines for deciding which
     storage method is appropriate for your application.
     Strings, in RIFF chunk;storage methods



     Usage                         Recommended Format
     Chunk data contains nothing   ZSTR (NULL-terminated
     except a string               string) format.
     Chunk data contains a number  String-table format
     of fields, some of which are
     variable-length strings
     Multiple chunks within the    String-table format
     file need to reference
     variable-length strings
     Chunk data stores a sequence  BZSTR (NULL-terminated
     of strings, some of which     string with byte size
     the application may want to   prefix) series
     skip
     Chunk data contains           A multiline string
     multiline strings             format



<end snip>

Hope this helps. ;0  I think I got this from ftp.cwi.nl/pub/audio/


> We could use the Open Content License (http://www.opencontent.org/).  This
> is an "open source" type license instead of a "free" license, but I think
> it is the best option available.  The "free" licenses like the GPL and the
> GFDL are not really appropriate for sound/artwork.

I would say that the open content license is akin to the LGPL. And I'm a little
uneasy about it. I don't have anything concrete against it, to me it seems
vague. I would like to see a Free license for sounds. 

<ego>
I wouldn't want any of my sounds to be stolen and end up in a non-Free product.
Unless of course I relicense it. ;)
</ego>

Hmm, I was going to "fork" the GFDL, but it's not really forkable, the FSF owes
it. Would it be impolite to fork the GFDL and then ask for a blessing?

> Note that gnome-audio and gnome-audio-extras are currently not
> licensed.  This really needs to be fixed since it means it is illegal for
> anybody except the copyright holder to copy or distribute
> them.   (Elliot?)
> 
> > 2. Definitions
> > 	a. How define a sound collection: soundtheme? soundset(MacOS)
> > soundpack?
> 
> I like "sound theme" (or "soundtheme").

Agree.
 
> > 	b. Sound format: *.au? *.wav?
> 
> They both seem to work with gnomecc and esd.  Are there technical reasons
> to prefer one over the other?

I *think* au is only 8 bit. I would say RIFF (wav) or AIFF (aif) should
be the standard format.  Not sure if AIFF is usable.
 
> > 3. Sound types
> > 	What type of sound shall we include into a soundtheme
> > 	-FX?
> > 	-sounds from daily life (for example telephone ringing)?
> > 	-voices associated  the dialogs?
> > 	-from movies, TV or Radio? 
> 
> I think any of these would be fine except ones which have potential
> copyright violations (movies, tv, and radio).  Does anybody know how "fair
> use" applies to recorded sounds?  Is it legal to take a 3 second clip of
> sound out of a movie and distribute it?  My guess is that it isn't, but I
> don't know for sure.

I would say to be safe, if the sound or part of the sound is not original then
it shouldn't be included.  The example of a telephone ringing could be
considered original, think of the telephone as an instrument.

Einsturzende Neubauten would be an example. Negativeland pushes the copyright
issues. (But NL encourges "sampling" of their music. :) 

 
> > 4. Sound dimension
> > 	Is there
> > 	-a limit of X MB for soundtheme?
> > 	-a limit of X Kb for each sound?
> 
> In general, I would say "no".  However, when it comes to packaging things
> this may be different.  For example, we could have:
> 
> 1) gnome-audio - this just has the default GNOME sound theme
> 
> 2) gnome-audio-themes - this has a small set(5?) of alternate GNOME sound
>  themes which have a reasonable size limit so that a person could download
> it over a modem. Presumably distributions will choose to ship this.
> 
> 3) gnome-audio-themes-extra - this is where any obscenely large themes
> or any themes which are not considered to be in the "best 5 themes" group
> go.  Distributions may not want to ship this due to its large size or the
> lack of a real need for more than 6 themes for most people.  People with
> lots of bandwidth who like to play with their systems will enjoy these.

Or just (sub?)package each theme separately?
 
> Alternately, we could choose to merge (1) and (2) into gnome-audio and
> then call (3) gnome-audio-themes.  Either way, we will probably put a size
> limit on a theme to be considered as a standard theme which get
> shipped.  Any idea what this size should be?  gnome-audio is 660kB in RPM
> form and it doesn't even have window manager events.

It's like obscenity, we'll know it when we see it. :)


I sent this to Dan last week, I've edited it for brevity.
Some of it is not Gnome related and somewhat ambitious. 

What I am envisioning is an all encompassing project, or sub-projects.

GNOME:

Desktop sounds/themes

Games

Docs
Record a human reading the docs.
Also any training material that should come about. (Books on tape/CD?)

Misc
Any recordings that GNOME wants done. This could include talks by
developers at conferences, meetings, LUG group presentations, etc. eg Miguel's
UNIX sucks talk. ;)


Outside GNOME:

I was told that Linux International is looking into setting up a contest for
the semi-official Linux start-up sound.

I was also told that RMS wants to record some PSA's (Public Service Announcements)
to be broadcasted on college radio statations.

Any Free Software/Open Source project that needs or wants a recording of
anything or sound efxs. Eg worldforge, or what ever.


Erik
-- 
All music aspires to the condition of muzak.