Bug#515949: vorbis encoder is broken on armel
Upstream bug report is https://trac.xiph.org/ticket/1526 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515949: vorbis encoder is broken on armel
This is bizarre. If I run oggenc on an ep9312 (armv4t) chip, I get an .ogg file that reproduces the sound correctly, but is significantly different (75% of the size) from the same encoding performed on x86, while on an Xscale (armv5te) and Cortex-a8 (armv7) I get different results again, and the ogg files are full of junk and decode to silence.. These are all up-to-date debian-armel-lenny installations with the same versions of vorbis-tools (1.2.0-5), libogg (1.1.3-4) and libvorbis0a libvorbisenc2 libvorbisfile3 (1.2.0.dfsg-3.1) installed. -rw-r--r-- 1 martin martin 346624 Mar 12 13:29 Happy-x86.ogg -rw-r--r-- 1 martin martin 262144 Mar 12 14:19 Happy-ep9312.ogg -rw-r--r-- 1 martin martin 186510 Mar 12 14:50 Happy-xscale.ogg -rw-r--r-- 1 martin martin 186510 Mar 12 14:55 Happy-cortex.ogg The ep9312, xscale and cortex boards are all using softfloat, which is 100% IEEE compliant, while the x86 performs intermediate calculations to 80 bits' precision instead of 64. Another difference is that the machines are running different versions of the linux kernel ep9312: 2.6.25 (custom compilation for TS7250 board) xscale: 2.6.26-1-iop32x (Michlmayr Debian kernel for n2100) cortex-a8: 2.6.27.15-omap (custom compilation from mainline + mainline omap patches) and ldd /usr/bin/oggenc loads the library components to different virtual addresses, presumably due to the kernel version differences. Building the original libvorbisenc tarball from xiph.org, the example_encoder fails similarly on all the ARM boards, producing different silent ogg files of the same length on the different systems, while a build on gentoo-arm-eabi-feroceon produces a shorter file. Since this is not a Debian-only problem, I am reporting this upstream at xiph.org, citing this bug report for info. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515949: vorbis encoder is broken on armel
Package: libvorbis Version: 1.2.0.dfsg User: debian-...@lists.debian.org Usertags: eabi oggenc and libvorbis' example_encoder do not seem to work at all on armel. $ oggenc Happy.wav works fine on x86 and arm, but on armel creates an output just over half the length it should be, which is mostly full of garbage. {Happy is a 30-second stereo 44.1 kHz wave file with a 44-byte header, nothing special) An extract from od -c Happy.ogg after the initial header: 0007600 \0 \0 \0 \0 \0 002 \0 \0 \0 004 004 O g g S \0 0007620 \0 \0 177 \0 \0 \0 \0 \0 \0 262 005 U + 002 \0 \0 0007640 \0353 225 346 377 001 001 001 001 001 001 001 001 001 001 0007660 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 001 * 0010040 001 001 001 001 001 001 001 001 001 021 021 021 021 021 021 021 0010060 021 021 021 021 021 021 021 021 021 021 021 021 021 021 021 021 * 0010240 021 021 021 021 021 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0010260 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0010440 \0 \0 \0 \0 \0 \0 \0 \0 244 i \0 \0 322 4 \0 \0 0010460 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 i \0 \0 322 4 \0 0010500 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 i \0 \0 322 4 0010520 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 i \0 \0 322 0010540 4 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 i \0 \0 0010560 322 4 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 i \0 0010600 \0 322 4 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 i 0010620 \0 \0 322 4 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 244 0010640 i \0 \0 322 4 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 (this 17-byte pattern of garbage repeats for most of the body of the file) Decoding such a file produces a WAV of the correct size with nothing but zero bytes in the audio data section. Other wav files of various provenance are similarly unsuccessful. It looks like libvorbis, rather than oggenc, libao or libogg, bcos its example encoder in the build directory obj-arm-linux-gnueabi/examples/example_encoder uses stdio to read the WAV file and fails similarly while speexenc, which also uses libogg to write files, works fine. FWIW this wave file is visible at http://martinwguy.co.uk/martin/test/Happy.wav but oggenc's giving the same kind of output from any wav file I supply it with. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org