Oggz 0.9.1 Release
------------------
Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump,
oggzdiff, oggzmerge, oggzrip and oggz-validate.
liboggz is a C library providing a simple programming interface for reading
and writing Ogg files and streams. Ogg is an interleaving data container
developed by Monty at Xiph.Org, originally to support the Ogg Vorbis audio
format.
This release is available as a source tarball at:
http://www.annodex.net/software/liboggz/download/liboggz-0.9.1.tar.gz
New in this release:
* Added new oggzinfo tool
-------------------------
oggzinfo displays information about the contents of Ogg files.
By default it displays basic information such as audio samplerate
and video dimensions:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$ oggzinfo 2004-12-04-cc-theora.ogg
Content-Duration: 00:01:54.748
Theora: serialno 1648191042
3442 packets in 251 pages, 13.7 packets/page
Video-Framerate: 29.970 fps
Video-Width: 160
Video-Height: 128
Vorbis: serialno 0317964026
4935 packets in 138 pages, 35.8 packets/page
Audio-Samplerate: 22000 Hz
Audio-Channels: 2
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
oggzinfo also has options to display the following information for
the entire file, and also for each logical bitstream:
- length in bytes, kB, MB, GB
- average bitrate in bps, kbps, Mbps, Gbps
- statistics on page lengths (maximum and standard deviation)
- statistics on packet lengths (maximum and standard deviation)
The man page for oggzinfo(1) can be read online at:
http://www.annodex.net/cgi-bin/man/man2html?query=oggzinfo
* Added new oggz-validate tool
------------------------------
oggz-validate checks the ordering of packets within an Ogg file, and
also checks that it complies with the Ogg bitstream mapping
restrictions.
The man page for oggz-validate(1) can be read online at:
http://www.annodex.net/cgi-bin/man/man2html?query=oggz-validate
* improved oggzdump tool
------------------------
oggzdump now displays packet lengths (in bytes, kB, MB, GB ;-)
and timestamps (rather than just byte offsets). It now interprets
theora granulepos as a split of keyframe|pframe:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
00:00:07.733: serialno 0539503247, granulepos 89|27, packetno 119: 277 bytes
0000: 506c a908 120e 3d0b 88d7 73e9 7227 227c Pl....= ..s.r'"|
0010: 9f40 7463 f789 87c1 8b79 043b 183c 946f .@tc.....y.;.<.o
0020: d1e3 3e47 0798 9fcd 61a9 f113 e261 d1ec ..>G....a....a..
...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
oggzdump now also has a --content-type (or -c) option for
specifying the name of a particular bitstream to dump:
oggzdump --content-type theora file.ogg
will dump only the packets in the theora logical bitstream.
The man page for oggzdump(1) can be read online at:
http://www.annodex.net/cgi-bin/man/man2html?query=oggzdump
* bugfix in oggzdiff tool
-------------------------
r1176: fix some typos in oggzdiff which prevented multiple hide
options from being specified
The man page for oggzdiff(1) can be read online at:
http://www.annodex.net/cgi-bin/man/man2html?query=oggzdiff
* liboggz: bugfix in raw seeking
--------------------------------
liboggz provides seeking by time or byte offsets in multitrack Ogg
files. It automatically handles time offsets for files containing
Theora, Speex, Vorbis, FLAC and CMML.
r1092: fix a bug in raw seeking, where doing a raw seek by bytes
and back again by time (to the original time point) hadn't
invalidated the cached time offset, hence the second seek was
considered unnecessary and skipped. This change correctly
invalidates the cached time offset when doing a raw byte seek.
* unnecessary optimisations in oggzrip tool
-------------------------------------------
Optimised packet filtering: filtering decisions are now made at the
start of each logical bitstream, not at every packet. Additionally,
the hardcoded limit of extracting no more than 64 logical bitstreams
from the input file was removed.
The man page for oggzrip(1) can be read online at:
http://www.annodex.net/cgi-bin/man/man2html?query=oggzrip
About Oggz
----------
Oggz comprises liboggz and the command-line tools oggzinfo, oggzdump,
oggzdiff, oggzmerge, oggzrip and oggz-validate.
liboggz supports the flexibility afforded by the Ogg file format while
presenting the following API niceties:
* Full API documentation
* Comprehensive test suite of read, write and seeking behavior.
The entire test suite can be run under valgrind if available.
* Developed and tested on GNU/Linux, Darwin/MacOSX, Win32 and
Symbian OS. May work on other Unix-like systems via GNU autoconf.
For Win32: nmake Makefiles, Visual Studio .NET 2003 solution files
and Visual C++ 6.0 workspace files are provided in the source
distribution.
* Strict adherence to the formatting requirements of Ogg bitstreams,
to ensure that only valid bitstreams are generated; writes can fail
if you try to write illegally structured packets.
* A simple, callback based open/read/close or open/write/close
interface to raw Ogg files.
* Writing automatically interleaves with packet queuing, and provides
callback based notification when this queue is empty
* A customisable seeking abstraction for seeking on multitrack Ogg
data. Seeking works easily and reliably on multitrack and multi-codec
streams, and can transparently parse Theora, Speex, Vorbis, FLAC,
CMML and Ogg Skeleton headers without requiring linking to those
libraries. This allows efficient use on servers and other devices
that need to parse and seek within Ogg files, but do not need to do
a full media decode.
Full documentation of the liboggz API, customization and installation,
and mux and demux examples can be read online at:
http://www.annodex.net/software/liboggz/html/
Tools
-----
The Oggz source tarball also contains the following command-line tools,
which are useful for debugging and testing Ogg bitstreams:
* oggzinfo: Display information about one or more Ogg files and
their bitstreams.
* oggzdump: Hexdump packets of an Ogg file, or revert an Ogg file
from such a hexdump.
* oggzdiff: Hexdump the packets of two Ogg files and output
differences Oggz is Free Software, available under a BSD-style
license.
* oggzmerge: Merge Ogg files together, interleaving pages in order
of presentation time.
* oggzrip: Extract one or more logical bitstreams from an Ogg file.
* oggz-validate: Validate the Ogg framing of one or more files.
License
-------
Oggz is Free Software, available under a BSD style license.
More information is available online at the Oggz homepage:
http://www.annodex.net/software/liboggz/
enjoy :)
--
Conrad Parker
Senior Software Engineer, Continuous Media Web, CSIRO Australia
http://www.annodex.net/http://www.ict.csiro.au/cmweb/
hi everyone!
we are currently setting up a stream network for lac2005 (http://lac.zkm.de)
since we are trying to provide video streams for the first time, i would
welcome testers to shake out any problems beforehand.
our master server is currently open for public testing at
http://lac2005.zkm.de:8000. in order to conserve bandwidth, the number
of clients is limited.
there is one video (un chien andalou by salvador dali) and one audio
stream (the jazz tune "melancia" played by a friend of mine) streamed in
two different bitrates each.
please test them (especially the video stream). since theora streaming
is quite bleeding-edge, few distros will support it out-of-the-box.
in order to generate some documentation for stream users, we have
borrowed frank barknechts wiki, please go to
http://footils.org/cms/pydiddy/wiki/LinuxAudioConference2005
and add hints for your own distro.
! note that after this initial test period, the master server will be
closed to the public again. during the conference, only relays will be
given access. you can tune to one of the relays instead. urls will be
posted real soon now.
anticipating some bug reports:
* yes, the video is black-and-white.
* yes, there is some (intentional) distortion in the audio stream.
* yes, there is currently no metadata displayed.
* yes, the streams are not continous, i.e. your player will quit after
the piece ends.
* yes, you will see greenish garbage at the beginning. that's your
player waiting for a theora keyframe.
like last year, there will be irc channels:
#lac2005 @ irc.freenode.net for general conference issues and feedback
from remote conference participants
#lac2005-tech @ irc.freenode.net for stream-related technical issues
if you have problems or success stories, share them on the lists or on irc.
best,
jörn
hi all,
just a short question about jack ...
the pointer that
void *jack_port_get_buffer (jack_port_t *, jack_nframes_t);
returns, is that 128 bit aligned (for simd use)?
thanks ... tim
--
mailto:TimBlechmann@gmx.de ICQ: 96771783
http://www.mokabar.tk
latest mp3: kMW.mp3
http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone
http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space
would say "I want to see the manager."
William S. Burroughs
Hello! I just joined the LAD-list to get some feedback on the following
topic:
Convolution is really nice - I use it all the time to get perfect reverb,
nice guitar amp-sound etc. The only serious drawback is the high
input-output latency of simple FFT based algorithms. I'd like to see if it
is possible to improve on this situation without sacrificing to much
efficiency.
If the impulse response (the FIR) is N samples long, the complexity of a
naive (non FFT) implementation scales as N, i.e. it uses N operations per
sample of input. A simple (single block overlap-add) scales as ln_2(N),
since FFT has complexity N ln_2(N).
If one wants both computational efficiency and low latency, one can do (at
least...?) two things:
1: Split the FIR in smaller blocks. This is fairly simple, but has a serious
drawback: As the latency, L, goes down, the efficiency of the algorithm
approaches the naive non-FFT implementation. So the computational cost
scales as N for "zero" (L<<N) latency.
2: Another approach is to split the FIR in blocks of different sizes, as can
be seen in the bottom figure of this page:
http://www.music.miami.edu/programs/mue/Research/jvandekieft/jvchapter2.htm
This approach has an obvious advantage in that it allows "zero" latency,
while still retaining some of the computational efficiency of the
high-latency FFT based method. As far as I can see, the complexity of this
algorithm scales as (ln_2(N))^2 for zero-latency. This is not as good as the
high latency efficiency of ln_2(N) - but still far better than using method
1. with low latency.
As far as I know, the programs I've come across so far (most notably
BruteFIR and Jack_convolve) uses method 1. to get low latency. This leads to
my first question:
Has anybody implemented method 2. in a jack application, or, more generally,
under GPL?. If not, are there any reasons that I'm not aware of, why one
should not choose algorithm 2 instead of 1?
The only difficulty I can see with method 2 is the scheduling of the
different sub tasks. One way to get smooth processor load, is to do the FFT
of the different block-sizes in different threads. This involves that the
computation of the smallest blocks (triggered by the jack callback
mechanism), should somehow preemt the thread doing the double sized blocks -
and this thread should in turn preemt the thread doing the quadruple size
FFT-blocks etc. According to the FFTW documentation the FFT algorithm is
thread-safe, and can be used in this way.
I don't have much experience with threads - and none of the resources I've
found seems to deal with this kind of realtime problem. Is the above a
stupid way to deal with the scheduling problem? And are there any resources
you know of, that describes this kind of problem in detail?
\Sune Mai
_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee®
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
I'm looking for someone going to LAC from Zurich (or travelling through it),
who can pick up a computer for me there and meet me at the LAC.
I'll be coming from Schotland myself, and want to use it for ALSA testing
among other things.
A bit a of a strange passenger I know. I promise it won't need a toilet
break along the way! For this and some other "more fleshy" travelmates see
http://footils.org/cms/pydiddy/wiki/GetToLac2005
Please resond to me and Tormod (on cc) if you can be of assistance.
Thanks,
Martin
Hi!
The aim is trivial:
- get some wav file,
- burn it to CD-R(W),
- rip it, get a copy,
- compare the original file with the copy.
If I understand well, the main problem here is to determine "the same
starting point" for each of files. Is there some kind of software which
may be useful in such comparison.
(probably, some of answer may be like this: "learn scheme/ruby and use
snd". I'm interested in more short way :-)
Andrew
Seems to be pretty good. The audio samples were flawless in XMMS. I
played the video files in the VideoLAN client. They seemed to be pretty
good, but the video was quite a bit jumpy in high-res mode (could be on
my end, of course).
On Wed, 6 Apr 2005 22:09 , Erik de Castro Lopo <erikd-lad(a)mega-nerd.com> sent:
>On Wed, 06 Apr 2005 00:31:15 -0500
>Shane lists(a)itsagesolutions.com> wrote:
>
>> Hey everyone. I have a bland but important question for everyone. Say
>> hypothetically a company is developing an audio product using lots of
>> GPL source, but for whatever marketing reasons asks for NDA concerning
>> the codebase. Lots of GPL work is referenced and at least dynamically
>> linked, and though the company has directly stated that it will release
>> the codebase publicly with the product release (once it is complete).
>>
>> I am curious as to the general feel in the community on such practices.
>> Would this 1) be a violation of the GPL,
>
>Yes.
>
>> 2) if it is how tolerant would
>> the OSS community be, considering the general good intent of the
>> project, and
>
>If any of my code is involved, I will prusue the matter.
>
>
>> 3) if I were asked to sign such a NDA would that document
>> be a binding agreement even if the NDA itself might be a violation of
>> the GPL since it is inherently counterintuitive to the intent of the
>> GPL.
>
>The GPL is pretty clear about this. The GPL comes into action when
>the binaries or code derived from GPL code is **distributed**.
>That means that you and the company can hack on whatever GPL code
>you like as long as they don't release a binary (under NDA or not).
>
If you are part of the company or a contractor to the company and the product
is not distributed outside the company you can do whatever you want with the code
without having to release it. If you are outside the company and have to sign an
NDA then I think that would be considered distribution and would therefore
violate the GPL. As Erik said, once it's distributed then it has to be released.
Jan
>
> From: Alfons Adriaensen <fons.adriaensen(a)alcatel.be>
> Date: 2005/04/06 on PM 01:00:45 GMT
> To: "The Linux Audio Developers' Mailing List"
> <linux-audio-dev(a)music.columbia.edu>
> Ämne: Re: [linux-audio-dev] FOSS-tools for realtime audio analysis?
>
> You may mave a look at JAAA, (JACK and ALSA Audio Analyser). This is
a
> realtime 'technical' (rather than musical) spectrum analyser,
designed
> to make accurate measurements. It will also generate sines and white
> Gaussian noise. It's at
>
> <http://users.skynet.be/solaris/linuxadio>
>
> You will also need some small shared libs available from the same
> place.
>
> I'm considering some additional functionality, and if you have any
> specific requirements I'd be interested to know.
>
Thanks! Actually, it's a friend of mine interested in something like
this. One thing that I know he was curious about was if it would be
possible to develop some kind of test-case for external hardware, which
could give an indication of whether something is wrong with it or not.
>From just taking a peek at it, I'm getting the impression that this is
mainly a graphical tool (which is really cool). Anyway, he's not afraid
of hacking if this is what he's looking for. Are features like these
anything you've considered/already implemented/interesting?
> I am also working on a Room Impulse Response measurement system using
> a sine sweep as the stimulus. First release expected in a about two
> months.
>
> --
> FA
>
>
>
>
>
> I would like to invite you all to have a look at The Freesound Project.
>
> -> http://freesound.iua.upf.edu/
>
> This project was started in the context of ICMC 2005, and is a website for creative-commons licensed audio material exchange. If you want to know more about the project (why it was started and what it's goals are) have a look at this page:
>
> -> http://freesound.iua.upf.edu/whatIsFreesound.php
>
> Don't hesitate to contact me (bdejong(a)iua.upf.edu) for more information or feedback.
>
>
> kindest regards,
>
> Xavier Serra
> ICMC 2005 Program Chair
>
> PS: please feel free to forward this message to relevant mailing lists or interested people.
>
>
--
/**********************************
********* Xavier Amatriain ********
****** Music Technology Group *****
** IUA- Universitat Pompeu Fabra **
****** www.iua.upf.es/~xamat ******
***********************************/