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 538630 - Shn Playback
Shn Playback
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: gst-libav
0.10.18
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 472224 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-06-16 15:41 UTC by Jonathan Séguin
Modified: 2008-06-20 13:36 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Jonathan Séguin 2008-06-16 15:41:05 UTC
Please describe the problem:
Shorten (.shn) playback is very poorly implemented. Most files will be very choppy, generate random sound or will not play. Some rare files will play but these lack seeking and/or tagging.

Steps to reproduce:
1. Open a newer .shn file throuh gstreamer (or an application that has it as backend)


Actual results:
Nothing or choppy sound (as if the file is being played but only half a second at a time with a 2 second pause in between). Sometimes the file will simply emit garbage noise.

Some shn are playable but they lack very important features such as seeking (being imbeded or from a .skt) and tagging.

Note : All these files work perfectly on Foobar with shn plugin through wine.

Expected results:
Same as any other lossless media, namely FLAC. (proper tagging, seeking, playback)

Does this happen every time?
Yes

Other information:
While the shorten format is not widely used anymore, certain people still rely heavily on it. Digital bootlegs have for ages been encoded in shn and collectors are asked, for the sake of preserving a piece of history, not to alter the files when sharing.

As a side note, xmms-xhn is the best playback of shn under linux. While tagging and embeded seeking are very limited, (early imbeded and .skt tables are recognised) it does play all files regardless.

I think this shouldent be too hard of a task and I thank you in advance on behalf of all linux audiophiles.
Comment 1 Jonathan Séguin 2008-06-16 15:46:24 UTC
*** Bug 472224 has been marked as a duplicate of this bug. ***
Comment 2 Sebastian Dröge (slomo) 2008-06-20 13:36:27 UTC
This is essentially a ffmpeg bug as it's decoder doesn't support seeking and most likely is the cause for all other bugs too. Please file this bug at https://roundup.mplayerhq.hu/roundup/ffmpeg/

(I might be wrong but you should get the same behaviour with every other ffmpeg-based application... like mplayer or xine)