Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Matroska Input Plugin (Read 31759 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Matroska Input Plugin

Reply #25 –
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.
[span style=\'font-size:8pt;line-height:100%\']I wouldn't know a subtle hint if it stood on my desk in a purple dress dancing and singing, "Subtle hints are here again!"[/span]

Matroska Input Plugin

Reply #26 –
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

Matroska Input Plugin

Reply #27 –
Is a new version of foo_matroska being released?

Matroska Input Plugin

Reply #28 –
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

Matroska Input Plugin

Reply #30 –
Quote
Check to see if the value is greater than the truncated version of itself and if so, round up. Since
if (13823.16 > 13823) 13823 + 1 = 13824 <-- The orginal sample number!

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

..not 
A riddle is a short sword attached to the next 2000 years.

Matroska Input Plugin

Reply #31 –
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.

Matroska Input Plugin

Reply #32 –
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.
Microsoft Windows: We can't script here, this is bat country.

Matroska Input Plugin

Reply #33 –
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.
A riddle is a short sword attached to the next 2000 years.

Matroska Input Plugin

Reply #34 –
@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.

Matroska Input Plugin

Reply #35 –
- 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).
Microsoft Windows: We can't script here, this is bat country.

Matroska Input Plugin

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

Matroska Input Plugin

Reply #37 –
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?)

Matroska Input Plugin

Reply #38 –
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.
Microsoft Windows: We can't script here, this is bat country.

Matroska Input Plugin

Reply #39 –
Quote
... reliable way to crash explorer with matroska shell extension installed...

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

Matroska Input Plugin

Reply #40 –
@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?

Matroska Input Plugin

Reply #41 –
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
Ladies and Gentlemen... we are floating in space.

Matroska Input Plugin

Reply #42 –
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).
Microsoft Windows: We can't script here, this is bat country.

Matroska Input Plugin

Reply #43 –
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.)

Matroska Input Plugin

Reply #44 –
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 ?

Matroska Input Plugin

Reply #45 –
Quote
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 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?

Matroska Input Plugin

Reply #46 –
@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.

Matroska Input Plugin

Reply #47 –
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.

Matroska Input Plugin

Reply #48 –
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 ....

Matroska Input Plugin

Reply #49 –
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 :
Code: [Select]
ERROR (foo_matroska) : Matroska: unable to find a '' packet decoder object.
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