For playback of mka files in foobar2000.
Website

Right now only MP3, AAC, and FLAC (with updated plugin) can be decoded in foobar2000 v0.7.6.

Do you plan to support chapters? I just tried mkvmerge to mux mp3 with chapters taken from CUE sheet, and foobar reports only first track (although it can play past that track). Also bitrate reported is 0 kBps...

Convert to mka (witin foobar) would be very cool, like that new convert to mp4 thing that was recently added

Messer: It did have chapter support in v0.1 but I mistakenly like the code inside a
#ifdef _DEBUG
...
#endif
So that only the Debug builds I was testing had it.

treech: Yes, I will be looking into that

thx a lot jcsston

jcsston,can you upload to http://pelit.koillismaa.fi/plugins/index.php?I can not visit your page

Uploaded

Still some work on chapters seems to be necessary: this time multiple tracks display fine and I can jump (instantly - yay!) to any track I want, but if I let foobar play to the end of track it keeps on playing but does not actually change to next track (remaining time displays 0:00, %_isplaying% indicator still points to previous track etc.).

jcsston does mka has support for replaygain tags? i tried to add it to a file but foobar locked up with 100% cpu usage on the end of the file

Same place

Almost After last chapter playback does not stop right away - it simply starts from the beginning of the file as if it were glued to the end of file.

edit: Nevermind. I've just reinstalled foobar and problem's gone. Thanks Jory, nice Christmas gift for all of us

edit 2: I tried to replaygain the MKA file with chapters, foobar had had scanned all tracks but didn't stop after last one so I aborted the operation (cleanly, without killing foobar). And now problem with last track is back again...

This project seems really cool. Good luck with it.

I am sorry to say but due to the abrasiveness and anti-matroska fb2k developers. I am
discontinuing this plugin.

I am leaving the source code up so that if someone else wishes to they can continue it.

If reporting bugs is received as being "anti-matroska", then so be it. I'll maintain it myself instead, thank you for doing initial work on it.
I'm sorry if you found my actions offending, but I find the seeking issue highly disturbing on music I listen to, and I know others who agree with me.

jcsston: Don't take it too hard. At least some of us users are happy for the idea of your plugin and at least i am waiting more from this.

i can't find anything offending here in this thread. please continue working on it or at least explain what you find "anti-mastroska" here... i think this is just a matter of misunderstanding.

I also like the ida of MKA files in foobar.

It would be awesome to be able to set up chapters for the tracks and include perhaps CD Cover images in the MKA file itself.

On a side note, is there any tool to convert a FLAC file with cue sheet and tag info into a MKA file with chapters and the proper tag info?

Have you tryed mkvtoolnix? There is good GUI also "mkvmerge GUI"

It probably wasn't posted in the thread, I think.

Any chance of having the formulas for fixing gapless playback listed here integrated into the Matroska input plugin?

I'm new to the Matroska container, but so far, I like what I see and what FB2K does with it. However, this is what I would *really* like:

If I have a CD with 10 tracks, I would like to end up with 1 (Matroska) file with 10 audio tracks. Each track would be tagged with the tracknumber and song title, while the containing file itself is tagged with the album title, artist, release date, and have the cover art attached. Right now, this is perfectly possible with the Matroska container, however...

In order for FB2K to play the file, I have to create a single audio track and divide it by chapters using a cue sheet. I'm limited to "MP3, AAC, and FLAC (with updated plugin)". (Is it not as simple as extracting the data and passing it to the appropriate codec?) And FB2K knows nothing about the container file's tags. (If I tag my chapters with title only and tag the file with artist, FB2K won't see the artist.)

While I can live with what I have now, I do want to say, simply, that this would be a nice goal to achieve.

Oh, and I do have one real issue. FB2K doesn't see the end of the Matroska file. It just keeps repeating the various songs within the file over and over, regardless of anything else in the playlist. (Sequence = random FB2K v0.7.6)

That is fixed in 0.7.7a.

As for everything else, that is a good point. You can tag things by Chapter, Track, or File in Matroska. Technically, you could have several albums in one file using one track for each album. Tag each Track with general info, and each Chapter with specific song info.

True. Personally, I think I would find myself using one track per song and using chapters within the track to delimit movements (classical music...). The question is, though, if FB2K will eventually support this and when, as well as support for reading both track/chapter tags *and* global file tags.

Just in case anyone is still developing this plugin - I thought I'd report that the Matroska tags applied by Foobar with the plugin are not valid Matroska tags. See here for more information.

I hope this plugin can be continued and the seeking/gapless issues resolved, using MKA for audio works great.

I've just had another issue crop up. Using FB2K v.0.7.7b, I can scan per-track and per-album replaygain values and they calculate correctly. Yet, the results don't get saved to the file... at least not in such a way that FB2K will read them the next time the file is loaded. It kinda sucks having to scan everything every day.

IMHO it doesn't make much sense to report any further bug of the matroska plugin here before FB2k0.8 is out including a new version by zZzZzZz.

Regards,
The Link

Is a new version of foo_matroska being released?

AFAIK 0.8 will be out soon so we will see if there's a new version or not (but I think so).

Regards,
The Link

Here is the official word on how to properly round for sample accurate seeking. This should be integrated into the foo_matroska plugin for proper playback of such files.

http://matroska.org/technical/specs/notes.html#TimecodeScale

How comforting to see that those Matroska people at least know the basics of truncating and rounding numbers.

..not

Okay, that would be my fault as I got really lazy at the end of typing that and adding the numbers. I guess the code should look more like this:
int sample;
sample = ceil(resultfromabove);
Unless of course you were wondering why you add one here. Its because sample 1 has a timecode of 0. Unless the first sample of an audio stream is sample zero and not sample one. If someone would let me know which it is, I would be glad to clarify.

Please try to keep the discussion civilized, everyone.
I'll try to implement this in foo_matroska when I have time, hopefully before 0.8 final.

Pamel: Yep, I understand the problem, I was just poking fun at the clumsy way the necessary rounding was expressed in that document.

No offense meant btw.

@ssamadhi97: Actually, I'm surprised that you are the first person to mention it. Especially that last line, I knew it wasn't good when I wrote it. But after looking for good examples and checking the numbers several times I didn't want to work on it any longer. It was on my todo list before, and it still is.

@zZzZzZz: I'm not sure if anyone mentioned this, but the problem mentioned earlier about the Tags not being written correctly, it is a problem with the Segment size not being updated. Effectively the Tags are being placed outside of the actual Matroska data, leading to problems with other apps. Let me know if you need more info.

- New rounding implemented.
- I talked to Christian about the tag writing problem some time ago, it was apparently copied from matroska shell extension, I need sample matroska tag writer source that doesn't have this problem (last time I checked matroska shell extension still had it).

The shell extension code was just updated and should no longer have this issue. Source is available here.

couple of questions on the status of the plugin (if you have time to answer zZzZzZz... you've been pretty busy of late it seems)...

1) What formats currently work in MKA containers?
2) Does the component currently distinguish between file, track, chapter, etc. tags in the MKA file?
3) Does the component allow the user to selectively write the different sorts of tags mentioned above?
4) Are the plans for some tools like the ones included for converting to/from mp4 files, but for MKA containers instead?

That's All.

Thanks zZzZzZz for upkeeping this component. I think MKA might have some future place (especially if FLAC cannot go into mp4 containers... or can it?)

Here is a test version. I copied the tagging code jcsston pointed; I think it still needs changes (truncate files correctly at the end ?). So far, it seems to be a highly reliable way to crash explorer with matroska shell extension installed. Any user feedback welcome.

Reliable crashes are so much easier to fix than random crashes. Please enable the Crash Catcher and send the report.

@zZzZzZz: I would like to finalize how the ReplayGain data is stored in the tags soon. As the first person that will likely have to implement this, do you have any particular preference?

I quickly tested the newest version (0.5) and everything seems to work fine. Tagging works and I haven't had any crashes. I'm using Matroskaprop 2.3. I use mkvmerge to mux the mp3 into mka and use the cuesheet to add chapters. Would this be the preferred way of doing this, or would adding a bunch of tracks also work in the future?

I see that the tags have a ChapterIUD and I suppose that is to keep each tracks' tags seperate. Could it be possible to make use of the global tags in matroska (without the target fields)? That would of coarse apply to all chapters.

Also I can't figure out a way to write the ChapterUID's with mkvmerge.

Matroska seems to be very usable as a album container already. Good work !!
A big fat thanks to all the developers for all your hard work. Keep it up

jcsston: http://foobar2000.org/temp/b0rk.mka - this seems to very reliably crash matroska shell extension 2.5, no idea why. On a side note, I don't see original matroska tag updater truncating file if new tags are shorter than previous ones. Perhaps tag readers/writers should be more integrated into libraries so this stuff doesn't have to be done in a specific way in each matroska-capable app.
Pamel: I currently store vorbis-style replaygain_track_gain, replaygain_track_peak, replaygain_album_gain and replaygain_album_peak metadata. I will implement any "more standardized" way you post, all I want is that new way should have at least same capabilities as replaygain_* metadata (make it possible to set these 4 values for each chapter).

I have started experimenting a little bit with FLAC inside of MKA containers.

I was wondering if the seeking issues have been addressed/fixed?

(I am guessing yes from what has been said, but I am a bit unsure.)

Time for me to test the new plugin it seems. Can it handle multiple audio tracks now already ?

BTW, How do we solve that if a file has multiple audio tracks and chapters ? Right now, each chapter entry will appear in the playlist like a song of its own, but what do we do if each audio track has its own chapters, or if the same chapters apply to more than one audio track ( typical for movies ) ?

List all the audio tracks name in the playlist, and indent the chapters for each track ?

I was originally thinking that you would just derive that replaygain data was for the album if it applied to more than one Chapter/Track, but this obviously wouldn't work if song were seperated by itself. So, 4 values it is. How about:

REPLAYGAIN_GAIN
REPLAYGAIN_PEAK
REPLAYGAIN_ALBUM_GAIN
REPLAYGAIN_ALBUM_PEAK

I think that there should be a normal replaygain with the album version being a special case. So, naming would reflect this. Would you provide me with some example replaygain data?

@zZzZzZz: How do you feel about the ideas for improving replaygain suggested in this thread? 2Bdecided has commented several times on it and there doesn't seem to be anyone against it. A different format that was incompatible with the original format could easily be labelled REPLAYGAIN2. And since any player that will support Matroska is undergoing active development, it shouldn't be difficult to switch too.

Either way, I need to know exactly how you want to store the replay gain information in the tags. There is apparently some confusion on it, and not everyone stores it the same way. But I would be happy to detail the specifications to how you store it so that it can be used as a base.

Are you storing ASCII text, binary data, INTs FLOATs - what? Or is that the problem - you don't know? Just pick one that works. People don't seem to argue with ASCII representations of deciaml numbers! Though it's hardly elegant.

If you follow the thread through, I don't change the basic definition of anything away from what's being done already. So, the ReplayGain is still a +/- number relative to 83+6dB (i.e. 89dB).

ReplayGains are typically between +12 and -15. One decimal place is more than enough, but some formats store 2.

Peak values can be below or above digital full scale, and have been stored as both simple normalised decimals using ASCI characters (e.g. 1.0000 for digital full scale), or binary representations with various formats. My preference at the moment is the 32-bit INT method described in that thread. If using an ASCII representation of decimal, you need at least enough accuracy to match 24 bits.


As for other values, I would appreciate it very much if you would include the proposed extensions in Matroska. (see http://www.hydrogenaudio.org/forums/index....showtopic=15445 )

(in the following, by "you need" I mean "you need to allow for a maximum of...")

1. You need one "(ReplayGain) undo adjustment" per track (always optional).
It would have a similar range to the actual ReplayGain values, but accuracy needs to be greater - several decimal places, though only one will normally be used.

2. You need one "ReplayGain calculation method" per ReplayGain value (optional for legacy values which don't have it already, but should be filled in for newly calculated ReplayGains).
Decimal value - probably 1, 2 or 3, but maybe 1.1, 2.01 - depends how many different tweaks and/or complete changes to the calculation are proposed!

3. You need one "ReplayGain lossy approximation" per ReplayGain or peak value (optional for legacy values which don't have it already, but should be filled in for newly calculated ReplayGains, or for any ReplayGains copied across when transcoding)
0 or 1.

4. You need one "ReplayGain user adjustment" per track (always optional).
Range same as other ReplayGain values.

5. You need one "ReplayGain RealLife adjustment" per track (always optional).
Range same as other ReplayGain values.


Does this help? Or hinder?

Cheers,
David.

P.S. If I appear to ignore you, it's only because I might not get chance to check HA next week.

No comments on the questions asked here ?

1. Improved Replay Gain - whats the best way of doing it

2. Does the plugin support all audio streams in a matroska file already ?

3. How do we handle chapters + tracks in the playlist ?

Please try to give us some hints ....

Hello,

first, thanks for this plug-in !

It seems that ac3 within a matroska file is not supported by the plug-in. With the current version (0.5, in the 0.8beta10), it returns an error :
whereas the standalone ac3 file is correctly played, and the mkv file is correctly played with media player classic (it contains a video and an ac3 stream, created with vdubmod 1.5.10.1).

Is is a bug, or just an unsupported feature ?

thanks