I'm glad to announce mka encoder, my new command line encoder for EAC (or may be other ripping tool). It permits to directly create a matroska audio file from EAC.
This .mka file is a single file backup of a CD (it contains the attached cue sheet).

To use it, you have to download the latest mkvtoolnix

You can download mka encoder here: mkaenc.rar (updated, now v 0.9.4)
Unpack it in your mkvtoolnix directory.

To use it in EAC:
Configure external encoder:
-> Use file extension ".mka"
-> Program: Path to mkaenc.exe
-> Additional command line options : -i %s -s "%o" -y "%Y" -g "%m" -m -f

Read doc/mkaenc.html or use "mkaenc -h" for help.

Bug report, comments or questions are welcome!

What is the codec of the stream muxed in mka?

I don't like using cue sheet to chapter, because precision is less than a sample (1/44100s)...

I used to think so too, but you never get sample precision with CDs. You always get rips in CD sectors, that is, 588 samples.

edit: Or maybe I'm misunderstanding you, ®om.

Yes (thanks for the information of 588, i didn't know),
but 588/44100=1/75=0,013333333333333333333333333333333
And 0,013333333333333333333333333333333 can't be EXACTLY a timestamp (illimited digit after dot), so we hav to round it at 0.01 or 0.013 with cue, which represent 573.3 (574) samples, and not 588, that we can get with 0.013333333=587,9999853 (588)...

I think matroska would have a "samplestamp based" or "sectorstamp based (588samples)" system (with timestamp, the user choose)

When I said CD sector, I meant CD frame.

You don't have to round. My cuesheets have notations like MM:SS:FF where MM is minute, SS is second, and FF is number of CD frames, so no fractions are involved whatsoever.

The accuracy issue has apparently been fixed as of April.

MKVtoolNIX changelog says:

I have no idea what the accuracy of the cue sheet is, but the accuracy will not suffer due to MKVtoolNIX or Matroska itself.

(Note that the problem was never Matroska; it has always had nanosecond resolution. MKVmerge just didn't used to use it)

REALLY????

Can u copy-past me one of your cuesheet?

@®om: I sent you one by PM. Ignore the first, and check the second, please.

mkaexe has been updated... it's now v 0.9.3.
I've fixed some minus bugs and it's not necessary any more to give ARTIST and TITLE on the command line as this tags will now be directly got from the CUE sheet :-) This permits to address a bug of EAC passing wrong tags on the command line (-a "%a") with various artists CD.

About cue sheet precision, I guess a CUE sheet is as precise as the CD itself... so no problemo! ;-)

MKVToolnix seems to consider INDEX 01 01:02:03 like 01mn, 02seconds and 03 centisecond instead of frames (comparing original flac number of samples and flac muxed in mka chaptered) (I read with foobar)

A bug of mkvtoolnix? (mkvmergegui)

®om: I would have to say that you probably shouldn't be worried about time precision so much....I remember it having been brought up before @ HA....

The TOC on the source CD's doesn't include frame based precision...
And AFAIK, Matroska doesn't have a frame (sample) based timing system available....probably a hangover from the video 'side' of it (the video is between 24~30 frames per second....audio precision is measured in milliseconds in most interleave formats.

Goldenear: :D

I will ask this to mosu if he didn't read the post yet.

While 10/3 cannot be represented perfectly accurately by a decimal number, it doesn't need to be. Pretty much every general application uses decimal timecodes internally, so you just need to have a level of precision better than the length of a single sample. Matroska also has specific rules for rounding to always find the correct sample. Given that a single audio sample for a CD lasts 1/44100 seconds, or about 0.02268ms, you could just use an accuracy of 0.01ms and always know the correct sample.

The default accuracy for Matroska is 1ms, as few will ever notice the difference. However, it is not an issue to use an accuracy of 0.01ms instead. I know that AVI-Mux GUI will automatically do this when writing an audio only Matroska file. I do not know if MKVMerge will though. Extra options may need to be specified.

@goldenear: Please make sure the accuracy is higher when writing these files.

@all: Anyone interested in know how the rounding occurs, or what level of accuracy is really needed can read more about it here.

The MKV/MKA muxing app can set any desired timebase for the stamps, so you may actually convert the timestamps into sample stamps if you want.

The only problem we are facing is, that the same timebase has to be used for all tracks in a file, so thats why for mkvmerge we keep the base in 10 , 100 or 1000 ns to be able to mux the existing video frame rates ( 23,97 fps, 24 fps, 25 fps, 29,97 fps and 30 fps ) without having to use strange timebases. The precision of 10 ns will be good enough for video in any case, if you understand that every single frame will typically last about 33 - 42 ms = 33000 to 42000 ns. The eye can not even see that these are single pictures, leave alone could they detect an timing error of less than 10 ns.

If a matroska files contains audio only ( MKA ) you are free to use whatever timebase is appropriate for your purpose and audio codec, like for MP3 you could set it to 1152 / 44100 s = 26122 ns , and the 'timestamp' in the block header would then be more like a 'sample number' with block #1 reading '1', block #2 reading '2', etc. .....

As mka encoder depends of mkvmerge, only mosu could precisely answer about how frames (hh:mm:ss.FF) informations are managed... :-)

This is an amazingly useful tool; thanks so much for it, goldenear. =) Unfortunately, I can't seem to change the encoder with the -e switch... it keeps erroring, "Unable to find encoder: 'C:\Program Files\FLAC\flac.exe'" I think the program is just ignoring the option switch.

Ariakis, are you sure to use the last version of mkaenc (v0.9.3) ? I just give a try with the -e switch and it works fine for me :-)

I you want to see what happens, just use the option -r "pause" so EAC won't close the encoding shell windows until you press a key.
Another trick is to use the secret -z switch wich activate the debug mode and will display everything that's happening.

The problem of rounding timecodes is with Foobar : when you re-extract separated tracks from a mka, it makes a mistake of 1 sample

Ahh, that did it. It was a problem with backslashes ending a previous quote, which threw everything else in the command line off. Thanks for the info. =)

Edit:
Just now, playing with it a little... It seems that your command line for mkvmerge doesn't work with Vorbis files, at least not ones encoded by the 1.1RC1 encoder.
The encoder options "-i %s -s %o -e "oggenc2.exe" -o "-q2" -x ".ogg" -m -f -z" in EAC yeild the following output: mkaenc.log

Also, why does the above command line change the disc's PERFORMER tag to "Various Artists"?

It does look like MKVmerge expects hundreths of a second, instead of frames for a cue sheet. I ran an MKA file through MKVinfo, and it said things like:

That's supposed to be 41 frames, not 41/100 of a second. I wonder if there's a way to change MKVmerge's handling of cue files? I see a --cue-chapter-name-format, but that doesn't seem to be it.

I wouldn't really say this was a bug in MKVmerge, since I don't know what the cue spec says the resolution of fractions-of-a-second ahould be. If it's supposed to be CD frames, then it looks like MKVmerge is wrong. If it's supposed to be 1/100 of a second, then EAC is wrong. If there is no spec, or fractions are undefined, then whoever backs down first is wrong.

About the mkvmerge issue, I don't know why it doesn't work... I'll try to see what's wrong.

About "Various Artists" issue... It was a MAJOR BUG!

Now fixed, please download and update to the new release (v0.9.4)

Cdrwin started it, I think. Cdrwin.hlp says:

Then it is a problem with MKVmerge's handling of cue files. Thanks for the info. I'll go bug Mosu.

Yes.

I strongly hope that hh:mm:ss.FF is not a valid format for the INDEX line. Judging from the other posts I guess that you really meant hh:mm:ff.

Try http://www.bunkus.org/videotools/mkvtoolni...d20040718-1.rar

What is the advantage to using a FLAC plus CUE inside of an MKA as opposed to just a CUE inside of a FLAC?

Thanks.

flloyd, this has ever been discussed here
.

Works great for me. Thanks, Mosu!

With a cuesheet, with mm:ss:ff, I've always the same bug with this beta release (01:02:03 -> 00:01:02.030000000)

Mosu, what the real format of timestamps in cue for make mmg work correctly? I can't find it...
HH:MM:FF : where are the SS ???

Doh... I meant mm:ss:ff of course. mkvmerge uses mm:ss:ff when reading INDEX lines from CUE sheets now. The beta I've uploaded yesterday _should_ do that. Please make sure that you're not using plain 0.9.3 (have a look at mmg's "Help -> About" menu, it should contain the time of the build. 0.9.3 was around 18:20 or sth like that, the beta should be around 23:10).

Ah yes I've the 18h20 release

Where can I find the new ?

Just redownload it from the mosu link

This is always the 18h28 release

Indeed, the about box display 18h28 but the files seems to have been build @ 23h16 (modification date)...

Wrong system clock on my Windows installation. Sorry for the confusion. The RAR's timestamp is the one that I meant. The about box displays the timestamp of the compilation which is set from the system clock from my Windows installation (which is wrong). The RAR's timestamp is the one when I've uploaded the file, timestamped with my Linux installation's clock (which is right).

Here how to go with Monkey's Audio:

problem:

Monkey's Audio needs at first the inputfile, then outputfile, then modes at commandline, FLAC has at first the options, then the inputfile etc.


Create a .bat-file with the following content into the directory of mkaenc (it's more simple to do this):



As you can see in my setup mac.exe has to be in the same directory like the mac.bat.

At Encoder-settings in EAC use a commandline akin to this:



%2 represents the -c3000 option (or any single-option you're using), if there are more (not really neccessary and AFAIK even not possible, don't want to check this right now) you have to use %3 etc. after the first %2.

Last night merging was not possible, the commandline (specially the filenames) were correct, I guess I have to use the latest mkvmerge.

Thanks to goldenear for this useful tool.

Monkey's audio is (for the moment) unmuxable in matroska.

I never took some details about matroska - hmm, now I still have to emphasize that I am still wondering this is not possible - it's a pitty isn't it ?
'kay, whatever, ape or flac, for temporarily storing - it doesn't matter (given in Wyclef style).

Very handy tool.

But unfortunately it doesn't seem to be able to handle the files whose name includes mulibytes characters such as Chinese or Japanese. Is there any way to solve this problem?

Since I'm not familiar with a command-line application, any help would be appreciated.

Thanks.

I'd like to request an easy way (a switch or something, perhaps) for setting per-frame-index-lookup-precision in an .mka-file.

Also, what is the state of using track-indices in matroska right now?

Huh? mkvmerge now correctly treats the timestamps in CUE sheets as MM:SS.FF with FF being frames in 1/75s. Or what exactly do you mean with this request?



Do you mean 'INDEX 00' and 'INDEX 01'? Current mkvtoolnix builds (available at http://www.bunkus.org/L?id=pre ) create hidden sub chapters for the INDEX entries so that the CUE sheet can be re-extracted from a Matroska file. Anyway, this is still work in progress (I'm working closely with goldenear on this, so I hope I'll have a new _release_ on Sunday).

mkvmerge cannot cope with such file names, I'm afraid.

Is there a way to use this with foobar and the command line disk writer plugin to make mka'a directly in foobar? That would have been awesome

Oh, it does? Well that's very nice, I just got confused from the precision given in this:




I read this as the frames (which are 1/75) being given as 370 million nanoseconds, 0.37 seconds.




I was thinking of the first, truly hidden pre-gap (00-01 of track one), and the other pregaps, as well as the indices 02-99 which a minority of CDs use. The way I read it, from the files above, is that the first pre-gap given by the cue is called a "segment track" and not included in the data for the chapters, which is fine, but there is also a gap between the first and the second track, and the second track doesn't really start at 3:47:37, does it?

If I have no idea what I am talking about, please do ignore me and get back to work, you're doing a great job.

With your CUE sheet I get the following:



mkvinfo always uses _timestamps_, so the .493 in the last example are milliseconds. Anyway, I don't know where you got those chapters from, but they do not come from a CUE sheet, at least not muxed directly with the latest mkvmerge.

Sorry to hear that.

But okay, I can use mmg to get along with mutilbytes file names, and the other usual names can be handled with this nice handy mkaenc to directly create mka files. Yes, they are still very handy, both of mkaenc and mkvtoolnix.

Anyway thanks for the info, and I hope it to support multibytes inputs someday. Considering that matroska has a lot of features that can be used under multi-language situations, I think many other users want this as well.

#Sorry about my English if it doesn't make sense.

Ogg/Vorbis problem solved! again a bug in mkaenc
Please update to makenc 0.9.5 HERE!
You can try it, it should now work with oggenc

*** IMPORTANT ***
If you plan to encode your entire CD collection, please wait mkaenc v. 1.0.0!
It will be available in the same time as the 0.9.5 release of mkvmerge.
******************

Until then, be aware that the extraction of a individual track (chapter) from a mka file in foobar won't be sample accurate. (Don't worry, if you demux the mka file with mkvextract the extracted audio file will be exactly the same as the original one )

Might you mean MKAenc?

Also, may I ask what the current versions of MKVmerge / MKAenc lack that we should know about before going nuts encoding? Is it just the sample-accurate decoding in Foobar, or is there anything else?

yep! (fixed)



some major improvements :
1) you won't need to attach the cue file anymore as mkvextract will be able to extract the cue sheet from the mka file structure. So you will not have to matter if the attached cue sheet to be in sync or not with the mka tags
2) mkvmerge will be more "time accurate" so splitting/extracting a mka file with foobar won't be any more an issue (you will always get the exact number of samples).
3) may be something else... you will see

I hope all this to be ready soon ... may be end of next week.