dir2ogg-0.8, (current stable) fails when converting mp3 with []() characters and cannot convert spaces to _. This also happens with gcc-3.4.6-r2. dir2ogg-0.9.x Segfaults even before attempting to convert the mp3 to wav. This happens with gcc-4.1.1-r3. With gcc-3.4.6-r2 seems to work fine. Already rebuilt the direct dependencies and this seems to be dir2ogg fault. All the 0.9 series suffer from this segfault problem. The results below are with 0.9.3. PS: Sorry about the two bugs in one report, but since no version works with gcc-4.1.1-r3, dir2ogg is useless atm. Thanks Reproducible: Always Steps to Reproduce: 1. dir2ogg -q5 -d test 2. 3. Actual Results: $ dir2ogg -q5 -d test (...) ############################################################################## High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2, and 3. Version 0.59q (2002/03/23). Written and copyrights by Joe Drew. Uses code from various people. See 'README' for more! THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! 01-sound(one).mp3: No such file or directory ############################################################################## (...) ERROR: Cannot open input file "01-sound(one).wav": No such file or directory ############################################################################## Traceback (most recent call last): File "/usr/bin/dir2ogg", line 331, in ? main() File "/usr/bin/dir2ogg", line 327, in main x.thruTheRinger(myopts) File "/usr/bin/dir2ogg", line 271, in thruTheRinger x.wavToOgg() File "/usr/bin/dir2ogg", line 230, in wavToOgg self.removeSong(self.songwav) File "/usr/bin/dir2ogg", line 101, in removeSong os.remove(song) OSError: [Errno 2] No such file or directory: '01-sound(one).wav' With dir2ogg-0.9.3: $ dir2ogg -q5 -d test dir2ogg Version 0.9.3 (fully Web 2.0 compliant!) :: Use at your own risk. Written by Darren Kirby :: d@badcomputer.org :: http://badcomputer.org/unix/dir2ogg/ Released under the Artistic License. Segmentation fault Portage 2.1.2.2 (default-linux/x86/2007.0, gcc-4.1.1, glibc-2.5-r0, 2.6.20-gentoo-r6 i686) ================================================================= System uname: 2.6.20-gentoo-r6 i686 Intel(R) Pentium(R) M processor 2.00GHz Gentoo Base System release 1.12.9 Timestamp of tree: Thu, 26 Apr 2007 14:50:01 +0000 dev-java/java-config: 1.3.7, 2.0.31-r5 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.15-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium-m -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/app-defaults /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-march=pentium-m -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://darkstar.ist.utl.pt/gentoo/ http://cesium.di.uminho.pt/pub/gentoo/ ftp://mirrors1.netvisao.pt/gentoo/" LANG="en_US.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://darkstar.ist.utl.pt/gentoo-portage" USE="X alsa crypt cups gif jpeg nptl opengl perl png python readline sdl sse sse2 ssl tiff truetype unicode x86 zlib" ALSA_CARDS="intel8x0 intel8x0m" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev fglrx vesa radeon" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Forgot to add this: The 1st part of the Actual Results is the output of dir2ogg-0.8 The 2nd is with dir2ogg-0.9.3
the fact is that dir2ogg is only a python script, so gcc has probably nothing to do with dir2ogg but rather its dependencies could you please upload somewhere the file that makes it crash so that I can try to reproduce it ? and it seems that you're using an old version of mpg123 (0.59q), now 0.65 is stable on your arch, perhaps I should just update the deps to that one if I can reproduce your problem
I'm actually using mpg321-0.2.10-r2 and not mpg123. But the author of dir2ogg claims that both apps are fully compatible. Bug 163026 addressed this. I tried several commands with mpg321 and it seems to work fine. I was able to reproduce the mp3 file and convert it to wav without any errors. With mplayer and oggenc everything is fine too. I tested dev-python/pyid3lib and it seems that this is in fact the cause. Already rebuilt this module but nothing changed. Have a look at these results yourself: Python 2.4.3 (#1, Apr 26 2007, 01:08:09) [GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pyid3lib >>> x = pyid3lib.tag( '13-Tiger_Stripes-Amphytrion.mp3' ) >>> x.artist '13-Tiger_Stripes-Amphytrion.mp' >>> x.title 'e\x00\x00i\x01\x00d\x00\x00\x83\x01\x00Z\x02\x00d\x01\x00S\x00\x00\x00\x00\x00' >>> x.title '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' >>> x.title 'e\x00\x00i\x01\x00d\x00\x00\x83\x01\x00Z\x02\x00d\x01\x00S\x00\x00\x00\x00\x00' >>> x.title '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' >>> x.title 'e\x00\x00i\x01\x00d\x00\x00\x83\x01\x00Z\x02\x00d\x01\x00S\x00\x00\x00\x00\x00' >>> x.title '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' >>> x.artist '13-Tiger_Stripes-Amphytrion.mp' >>> x.artist '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' >>> I think you can test it with any mp3, but anyway, here is copy of the file: http://apollo.dq.fct.unl.pt/~al1133/13-Tiger_Stripes-Amphytrion.mp3 I already reported this issue upstream: http://sourceforge.net/tracker/index.php?func=detail&aid=1709003&group_id=49949&atid=458058 Thanks
Can any gentoo dev confirm (and possibly fix) this? dev-python/pyid3lib at sourceforge seems to be in a deep hibernation and unmaintained. Resolve as UPSTREAM ?
At first, I am no Gentoo User, but I want to help you: I am running Debian Etch, with * gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) * glibc 2.3.6 * id3lib 3.8.3 * pyid3lib 0.5.1 and I can not reproduce this bug with my MP3 File.
I tried to check a couple of mp3 and I couldn't reproduce it either. After a bit of digging I found that the problem was that (and I have no idea why) all the mp3 files of the album (from where the initial mp3 files was) have ID3v1 and ID3v2 with corrupted ID3v2. The problem was specific to this album and it didn't happen with other files. Tagtool was able to read the ID3v2 and the ID3v1, but it hang when saving changes. So strangely this was also affecting tagtool. So I tried removing and recreating the ID3s. 1st the v1 and then the v2. After deleting and recreating the v2 the problem was fixed. Tagtool also has one option that allows you to copy v1 to v2 and v2 to v1. If I copy v2 to v1 there is no problem. If I copy v1 to v2 without removing v2 first, all the fields get something like "(35)". Sorry to report a bug that was actually file specific. Since other tag editors and mp3 players where able to read the tags I never remembered of trying to edit the tags first. Also when I tried other mp3, they were from the same album, so the problem was consistent. Thanks Julian Andres Klode for your reply. It made me grab the files again, test a little bit more with several different files and reach the conclusion that the bug was not with the pyid3lib but with the ID3v2 of those files.
