Bug 334732 – [id3demux] mp3 fails to play because typefinding thinks it's AAC

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 334732 - [id3demux] mp3 fails to play because typefinding thinks it's AAC


Summary:	[id3demux] mp3 fails to play because typefinding thinks it's AAC


Status:	RESOLVED FIXED

Product:	GStreamer
Classification:	Platform
Component:	gst-plugins-good
Version:	0.10.2
Hardware:	Other All

Importance:	Normal minor
Target Milestone:	0.10.3
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2006-03-16 08:43 UTC by Richard Edmands
Modified:	2006-03-16 12:48 UTC

See Also:
GNOME target:	---
GNOME version:	2.13/2.14

Description Richard Edmands 2006-03-16 08:43:35 UTC

Please describe the problem:
yeah, i have this particular mp3 (which is part of an album).

"***@****:~$ gst-launch-0.10 playbin uri=file:///home/****/iTunes\
Music/t.A.T.u/Dangerous\ And\ Moving/11\ Obizienka\ Nol.mp3
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /playbin0/decoder/faad0: Could not decode stream.
Additional debug info:
gstfaad.c(894): gst_faad_chain (): /playbin0/decoder/faad0:
Failed to init decoder from stream
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
FREEING pipeline ..."

all my other mp3's are fine, and that mp3 plays fine in all other tested media
players "mplayer, xine, iTunes, Windows Media Player"

Steps to reproduce:
read above

Actual results:
read above

Expected results:
for it to play the song :)

Does this happen every time?
Yes! (even happens on 2 different machines, so a corrupt install is unlikely)

Other information:
i will attempt to be in irc.freenode.net #gstreamer DarkMageZ

Comment 1 Tim-Philipp Müller 2006-03-16 12:48:09 UTC

This looks like an id3demux typefinding problem. The file has been verified to work fine with current CVS (which does typefinding pull-based if supported).