matroska Foobar2k implementation

Hi Jory,

here an interesting IRC log from #foobar2000 on irc.freenode.net for you 
( sorry about the short rant in the middle ;-) ) :

---------------------------------------------------------------------------------------------------

<DEATH> wrap mp3/mpc into matroska then kill all improvements it gives 
over raw mp3/mpc
<adiabatic> what's the point of MPC-in-Matroska, anyway?
<DEATH> mpc seeking ist death
<DEATH> inefficient
* CompactDick concurs
<DEATH> think playing mpc+cue over LAN
<ChrHJW_Zhengzhou> yup :)
<DEATH> same goes for mp3
<CompactDick> you can feel the lag on a slower machine, like my PII 366
<CompactDick> ogg works fine here
* ChrHJW_Zhengzhou is still working on his first FLAC + CUE in MKA ed2k 
release, with chapters and other Goodies ...
<DEATH> i made mpc+cue behave semi-decently when playing from local hdd 
on athlonxp
<CompactDick> as it should
<DEATH> but it is still ass in algorithm efficiency terms
* ChrHJW_Zhengzhou is now known as ChrHJW_Beijing
<DEATH> ChrHJW_whatever: some people seem to want to implement mka 
support in fb2k using reader api
<DEATH> that would kill fast seeking
<ChrHJW_Beijing> i understand this is no good idea ?
<ChrHJW_Beijing> oh ...
<DEATH> probably can be hacked to work at all but it is no good
<ChrHJW_Beijing> who are this people ?
<ChrHJW_Beijing> can we convince them to make it better ?
<DEATH> <jcsston> ah, I think I've found the problem. the file class 
handles different 'protocols' file://, http://, etc.(to my 
understanding) if I add a matroska file as a location like 
'matroska://C:/test.mka' the matroska file class is called :) I'm 
guessing that with the default 'file://' the internal file class was 
handling it
<DEATH> havent been able to communicate with him
<DEATH> but he seems to want to emulate reading from a raw mpc file
<ChrHJW_Beijing> oh, Jory
<ChrHJW_Beijing> i talk to him
<DEATH> so no fast seeking for you
<ChrHJW_Beijing> you have a message for him i can transfer ?
<DEATH> lemme say this again
<ChrHJW_Beijing> [email protected]
* ChrHJW_Beijing is logging
<DEATH> you need some kind of third-party-extendable interface that 
turns mpc/mp3/whatever compressed packets into audio data, right ?
<DEATH> add your own interface class to fb2k and let others implement it
<adiabatic> MTRH: A (fairly dated, since there's over a billion of 'em 
now) Monty Python song.
<DEATH> like i did with packet_decoder in 0.7.6 (for MP4 playback)
<ChrHJW_Beijing> got you
<ChrHJW_Beijing> if we add this class, is there a collision with a 
normal MKA reader ?
<DEATH> if you cant get stuff working with packet_decoder interface i 
have in 0.7.6, write your own interface, and i'll add that interface to 
mp3/mpc/vorbis/aac/whatever decoders in foo_input_std
<DEATH> ?
<ChrHJW_Beijing> or can he finish his work to have a first support ?
<ChrHJW_Beijing> even if its suboptimal that way ?
<DEATH> lemme flood how mp4 parsing works again
<DEATH> there is input_mp4 class, which is just like any other input
<DEATH> but it finds packet_decoder interface that can handle data type 
contained in mp4 file being read
<DEATH> and uses that decoder
<DEATH> like writing plugins to a plugin
<DEATH> ideally, MKA could do the same logic
<DEATH> main problem is that you need to be able to call different 
(often third-party-supplied) audio decoders, right ?
<DEATH> anyway, take 0.7.6 mp4 parser as sample code
<ChrHJW_Beijing> sounds good
<DEATH> in foo_input_std
* ChrHJW_Beijing is again wondering about the way jcsston is working .. 
he is always coding first, and communicating afterwards :/ ....
<DEATH> hmm
<DEATH> do you have sample commandline decoder or smth
<DEATH> maybe i should look into implementing that myself
<DEATH> since this thing will probably get popular
<DEATH> would be better if this used same decoder API as mp4
<DEATH> which may involve changes in that api
<DEATH> bbl
-----------------------------------------------------------------------------------------------------