Bug 115135

Btw. the description came in via the opensuse mailing list.

>I've put packages for testing at: ftp://ftp.suse.com/pub/people/aj/libogg/ and
would like to get feedback whether this fixes the problem.
-----
I think libogg is not the problem.
i have rebuild libvorbis with -fno-strict-aliasing and i think it is ok.

-rw-r--r--  1 michael users  4061 2005-09-04 04:08
libvorbis_beta4_-fno-strict-aliasing.ogg
-rw-r--r--  1 michael users  4085 2005-09-04 04:18 libvorbis_suse93.ogg

The sound quality is now (with -fno-strict-aliasing) ok and i think the file
size different is no problem.(imho different source ?)

mfg




But the file size is still different. 

^^^ Forget the last line. ;)

I didn't know that we have both libogg and libvorbis.  Argh.

Ok, will build libvorbis now.

ftp://ftp.suse.com/pub/people/aj/libvorbis contains new packages.  Could you
test them as well, please?

Thanks!

I made some tests. The recompiled libogg from above didn't changed anything .

With the recompiled libvorbis from comment #5:

I get much smaller ogg files than with the libvorbis from beta4. They are still
bigger than with SUSE 9.3's libvorbis, but only by less than 1%. Thus I would
say the size problem is fixed.

Sound quality seems fine with me too, but I have neither golden Ears nor super
high quality sound equipment.

Ok, libvorbis has been submitted for RC1 now, so we've workarounded the issue.

Michael, I would appreciate if somebody in the GCC time could look into this.

This will be PITA to reduce, but I'll try.  Someone can hand me some
earphones/speakers or a .wav + good + bad ogg file?

Thx.

>Someone can hand me some earphones/speakers or a .wav + good + bad ogg file?
---
Good joke, look:

libvorbis-1.1.0-7 (-fno-strict-aliasing)

-rw-r--r--  1 michael users 17757644 2005-09-04 17:44 she_is_a_diamond.wav
oggenc -q4 

gcc331.ogg--Total data length: 1553565 bytes--Average bitrate: 123,462119 kbps
gcc335.ogg--Total data length: 1553559 bytes--Average bitrate: 123,461642 kbps
gcc402.ogg--Total data length: 1553586 bytes--Average bitrate: 123,463788 kbps

What is good and what is bad? ;)

I think, the libvorbis with -fno-strict-aliasing is ok -for now.

mfg

Michael, the issue is workarounded for RC1.  But we'd like to fix the real bug.

If there is no crackling or loud noice etc., judging the sound quality is a  
highly subjective thing.  
       
I for example was not able to hear any difference in my few tests (I used some 
classic music, maybe it is triggered only with electric guitar sounds or 
something like that, who knows).  
  
Thus I think the main issue here is to watch the size of the resulting files.  
Like in the bug description 5940599 bytes instead of 4182508 is a big 
difference. I doesn't matter if it's 4.0 or 4.1 MB but if it's nearly 6MB, 
than there's something wrong. And this is fairly easy to reproduce. Just get 
some wave of 20MB or more and oggenc' it. 

(In reply to comment #6)
> I get much smaller ogg files than with the libvorbis from beta4. They are still
> bigger than with SUSE 9.3's libvorbis, but only by less than 1%. Thus I would
> say the size problem is fixed.

The libvorbis of betta4 and suse 9,3 are not comparable.
libvorbis SuSE9.3 = aoTuV b3 [20041120]
libvorbis betta4 = aoTuV b4 [20050617]

mfg

Created attachment 48763 [details]
updated type-punning patch

I was not able to reproduce the file-size difference, and encoded files differ
even with different runs of the
same executable as follows:

/tmp/mozart.bad.ogg /tmp/mozart.fixed.ogg differ: byte 15, line 1

(oggenc --serial=0 -q4)

Nevertheless, two potential bugs fixed in scales.c
with the updated type-punning patch (untested, no audio, but produces same size
files).  The difference
with -O3 the Xiph report saw can be explained by some
of the functions being only static but not static inline.

(In reply to comment #13)
/tmp/mozart.bad.ogg /tmp/mozart.fixed.ogg differ: byte 15, line 1
---
Yes, but this is no problem if the sound is the same. And the sound is the same!

oggenc -q4 she_is_a_diamond.wav -o she_is_a_diamond-run1.ogg
oggenc -q4 she_is_a_diamond.wav -o she_is_a_diamond-run2.ogg
oggenc -q4 she_is_a_diamond.wav -o she_is_a_diamond-run3.ogg
^^ all the same libvorbis and gcc

ogginfo *.ogg | grep "Total data length"
        Total data length: 1553586 bytes
        Total data length: 1553586 bytes
        Total data length: 1553586 bytes
ogginfo *.ogg | grep "Average bitrate:"
        Average bitrate: 123,463788 kbps
        Average bitrate: 123,463788 kbps
        Average bitrate: 123,463788 kbps

mfg

Created attachment 48777 [details]
Patch committed to libvorbis SVN to fix this issue

Thanks to Richard Guenther, we have a fix for the problem (which is indeed in
libvorbis).

I've attached a patch I just committed to libvorbis SVN (I'd expect it to apply
cleanly to the most recent release, if you prefer that).

Richard: the reason you were getting different files is that oggenc chooses a
random serial number for each encode. A bug (fixed in svn about a month ago) in
oggenc meant that choosing a fixed serial number of zero didn't work (any other
number did). Sorry about that.

Hmm.
Is the problem really fixed? If yes, which file is then the correct?

libvorbis_gcc335_Richard.ogg--Total data length: 1553559 bytes--Average bitrate:
123,461642 kbps
libvorbis_gcc402_Richard.ogg--Total data length: 1553613 bytes--Average bitrate:
123,465934 kbps

mfg

You cannot easily compare gcc-3.3.5 and gcc-4.0.2 output because
 1. you are using FP math on a x86 machine
 2. you are using -ffast-math for compilation

If you really want to compare them (and still then it's not a correct
comparison) at least avoid excess precision by using -mfpmath=sse and
don't use -ffast-math.

If both files are a reasonable encoding of the file wrt quality and filesize
then the bug is fixed (and may have been never there, as I really could not
reproduce the bug with my two sample input .wav files).  Still the "fix" is
correct and needed, but maybe for a totally different reason.

Richard.

It was not my intention to discredit your patch.
The patch works fine and does what it is to do.

A simple make should come to a same result. 
Everything else is badly and a mistake.

Ok, this is no topic for the openSUSE bugzilla.  

eot for me
mfg

"The patch works fine and does what it is to do." and no more input suggests
that this is fixed (upstream at least).  Packager/reporter, can you confirm
this was fixed for 10.0?

Let's assume it's fixed.