Nautilus and Totem report incorrect information with regards to ABR-encoded MP3s. The MP3's bitrate, length and type are incorrect when viewed in Nautilus' 'Audio' tab (right-click > properties > audio) or Totem's 'properties' dialogue (Movie menu > properties). The MP3s in question were encoded with LAME (3.96.1) using the following command: lame -vc -q0 -m s --abr 320 --nogap *.wav
Created attachment 80363 [details] Demonstration screenshot This is a screenshot showing what I mean. The actual average bitrate is 320 kbps, the track duration is actually 3:52 mins and the codec is actually MPEG 1 Layer 3 ABR.
your 'emerge info' please ? This is really an audio back-end problem, which is probably gst. Afaik gst 0.8 always had problems with abr files, not sure if 0.10 fixes this.
I neglected to mention that Totem is using the xine-lib backend, my apologies. As requested, though, here's my 'emerge info': Portage 2.0.54 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.15.1-rms x86_64) ================================================================= System uname: 2.6.15.1-rms x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=athlon64 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon64 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo" LC_ALL="en_GB.UTF-8" LINGUAS="en_GB" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X acpi alsa audiofile avi berkdb bitmap-fonts bzip2 cairo cdr crypt cups dvd eds emboss encode erandom esd exif expat fam flac foomaticdb fortran gif glitz glut gmp gnome gnutls gpm gstreamer gtk gtk2 gtkhtml hal howl imlib jpeg lcms lzw lzw-tiff mad mhash mng mp3 mpeg ncurses nls nptl nptlonly nvidia ogg openal opengl pam pdflib perl png python quicktime readline samba sdl speex spell ssl svg symlink tcpd threads tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis xine xml2 xpm xv zlib linguas_en_GB userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS, PORTDIR_OVERLAY
Then it's a xine-lib problem. Does 'ldd /usr/bin/totem | grep gst' give zero output ?
Hmm does nautilus use xine too?
I'm not sure if the problem is with xine at all, it might be with lame, because also KDE's kfile shows the same values, and that does not use xine at all. Maybe it's a problem with lame.
The media tab is a nautilus extension implemented by totem (equery f totem | grep naut). My current tab actually gives N/A for both fields (gst-0.10), not sure what 0.8 would do. My guess is kfile and xine might be using the same mp3 lib to fetch those stats ?
Foser: "ldd /usr/bin/totem | grep gst" returns nothing at all.
No, kfile uses taglib and xine uses internal decoder (or libmad, not sure).
Okay seems like to get the real average bitrate it would require to read the whole file every time, quite a difficult task, especially for streams. I'd say to leave that upstream, so if you really want this fixed, please report it on xine-devel mailing list.
