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 551659 - Add MT9 audio files
Add MT9 audio files
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: dont know
0.10.x
Other All
: Normal enhancement
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-09-10 14:23 UTC by Andreas Moog
Modified: 2010-06-17 21:24 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Andreas Moog 2008-09-10 14:23:55 UTC
This is a wishlist bug report. Free file formats could mimic the functionality of MT9 if the media players handled multiplexed audio. Currently, they do not

More specifically, support dynamically mixing several logical tracks from the input stream

About MT9:
http://www.guardian.co.uk/music/2008/may/27/news.seanmichaels

First reported on Launchpad:
https://bugs.edge.launchpad.net/ubuntu/+source/totem/+bug/259044
Comment 1 Bastien Nocera 2008-09-10 14:36:39 UTC
That's all fine, but we'd need to be able to support MT9 files in the first place...
Comment 2 kxra 2008-09-10 19:54:22 UTC
(In reply to comment #1)
> That's all fine, but we'd need to be able to support MT9 files in the first
> place...
> 

No we don't. This bug is just to support the same functionality which is possible with existing formats. 

Another problem with this is on the side of the containers. This is all new so no real standard exists for doing this. It can't be addressed form this end though. Just saying, something needs to be done to make this as easy as possible for artists.
Comment 3 Bastien Nocera 2008-09-11 01:39:15 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > That's all fine, but we'd need to be able to support MT9 files in the first
> > place...
> > 
> 
> No we don't.

Yes we do. If no formats supporting this are supported in GStreamer, or the one and only format supporting it isn't supported, what's the point in implementing infrastructure for the whole thing?
Comment 4 kxra 2008-09-11 01:48:17 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > That's all fine, but we'd need to be able to support MT9 files in the first
> > > place...
> > > 
> > 
> > No we don't.
> 
> Yes we do. If no formats supporting this are supported in GStreamer, or the one
> and only format supporting it isn't supported, what's the point in implementing
> infrastructure for the whole thing?
> 

Ogg is capable of doing this. It's simply mixing multitrack audio. For example, if i have multiple tracks in an ogg file, one is the vocals, another is guitar, another bass, etc, i should be able to control which ones i hear and how loud each one is. This is what is meant by supporting MT9 functionality. Although support for the MT9 format is also missing. 
Comment 5 Tim-Philipp Müller 2009-05-31 19:43:07 UTC
> Ogg is capable of doing this. It's simply mixing multitrack audio. For example,
> if i have multiple tracks in an ogg file, one is the vocals, another is guitar,
> another bass, etc, i should be able to control which ones i hear and how loud
> each one is. This is what is meant by supporting MT9 functionality. Although
> support for the MT9 format is also missing. 

I'm not sure what exactly you're asking for. I believe GStreamer can already do this just fine, e.g. via adder and a volume element for each input stream.
Comment 6 kxra 2009-06-09 20:25:02 UTC
Perhaps this is not a bug in gstreamer, but individual music players? For example, the media player needs an interface to be able to see the volume levels of each audio track to be able to adjust them
Comment 7 Tim-Philipp Müller 2009-06-14 11:38:30 UTC
> Perhaps this is not a bug in gstreamer, but individual music players? For
> example, the media player needs an interface to be able to see the volume
> levels of each audio track to be able to adjust them

I still don't really understand what exactly you're after, but I'm fairly sure GStreamer can do what you want already, so unless you can provide some more details of what you're looking for at the GStreamer level I'm going to close this bug and suggest you file bugs with feature requests against individual applications.

Normal media players will play back only one audio track at a time, so one volume control for that track should be sufficient IMO. Maybe you're looking for something like jokosher?
 
Comment 8 kxra 2009-06-14 19:14:12 UTC
You're right. This isn't a bug in gstreamer. For this to happen, music players must be able to play multiple tracks contained in an audiofile simultaneously, and have a separate volume bar for each one. For example, and ogg file could contain a song with a separate track for the audio, guitar, and drums. The media players needs to be able to play all of them at once, and adjust the volume for each track separately. So yes, close this bug
Comment 9 kxra 2009-06-14 19:31:40 UTC
I filed this in Rhythmbox here: http://bugzilla.gnome.org/show_bug.cgi?id=585770
Comment 10 Tim-Philipp Müller 2009-06-14 19:57:35 UTC
Ok, thanks for your comments. Sounds like you want the playback part of a multi-track editor like jokosher in standard media players like rhythmbox or banshee. I think a specialised media player would be more suitable for this kind of thing.
Comment 11 Bastien Nocera 2009-06-14 20:29:32 UTC
It's not because one of the commenters went on a crackful tangent that we should close this. We'd still like MT9 audio files support.
Comment 12 Tim-Philipp Müller 2009-06-14 22:16:36 UTC
> It's not because one of the commenters went on a crackful tangent that we
> should close this.

Ah, sorry, I missed the fact that he was not the original bug reporter.


> We'd still like MT9 audio files support.

Ok, so where can we find sample files and/or specs then?
Comment 13 kxra 2009-06-14 22:52:17 UTC
I was the original reporter on launchpad and the "original bug reporter" here simply copied my text =]

Either way, i support leaving this bug open to add support for the actual MT9 format. 
Comment 14 Tobias Mueller 2010-01-06 21:12:27 UTC
Danny, could you please answer the question in comment #12, i.e. where we can find specs and sample files? Thanks in advance!
Comment 15 kxra 2010-01-06 21:35:48 UTC
Following links from wikipedia, http://en.wikipedia.org/wiki/MT9 the group that created mt9 is here: http://www.etri.re.kr/eng/

Samples are here: http://www.audizen.com/company0905/music20/sample.asp
Comment 16 Tim-Philipp Müller 2010-01-06 23:32:40 UTC
Ok, so there are samples in one of the .zip files with the binaries.

However, realistically we'd still need either something approximating a spec or source code for the container and/or the audio format to do anything about this.
Comment 17 Tobias Mueller 2010-03-09 11:14:26 UTC
Danny, could you please answer the question in comment #16?

A quick research didn't get me the desired results, but an interesting post on the FLAC list: http://lists.xiph.org/pipermail/flac/2008-August/001258.html
Apparently it is (technically) possibly to multiplex many channels in a OGG file, dunno how the applications handle that though.
Comment 18 kxra 2010-03-09 17:02:36 UTC
<<Danny, could you please answer the question in comment #16?>>

I don't see a question there. I found all that i could. Perhaps someone more resourceful than me could find more

<<A quick research didn't get me the desired results, but an interesting post on
the FLAC list: http://lists.xiph.org/pipermail/flac/2008-August/001258.html
Apparently it is (technically) possibly to multiplex many channels in a OGG
file, dunno how the applications handle that though.>>

That's what Bug 585770 is for =]
Comment 19 Tobias Mueller 2010-04-26 19:19:00 UTC
Reopening as per last comment.
Comment 20 Tim-Philipp Müller 2010-04-26 22:27:58 UTC
> <<Danny, could you please answer the question in comment #16?>>
> 
> I don't see a question there.

Even if not phrased as a question, the need for more/better information, if not proper specs, was (I believe) clearly articulated... but, just to make sure: could you point us to either at least vaguely resembling technical specs for the format, or to an existing open-source implementation of this format somewhere?


> I found all that i could. Perhaps someone more resourceful than me could find more

Well, it's not really enough for us to do anything about this bug I'm afraid.

A better place to file this feature request would be with the ffmpeg folks, they tend to do most of the codec reverse engineering.

Setting to NEEDINFO again since we still don't have enough info to do anything about this. If the reporter and no one else can supply that info, and no one intends to work on this, then I'm not sure how much point there is in keeping this bug open.
Comment 21 Tobias Mueller 2010-06-17 21:24:49 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!