New command-line encoder for EAC, to directly create a mka file Options

[goldenear]

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!

This post has been edited by goldenear: Jul 18 2004, 21:27

[®om]

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)...

This post has been edited by ®om: Jul 16 2004, 23:32

[kjoonlee]

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.

This post has been edited by kjoonlee: Jul 16 2004, 23:39

[®om]

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)

This post has been edited by ®om: Jul 16 2004, 23:47

[kjoonlee]

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.

[Omion]

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)...

The accuracy issue has apparently been fixed as of April.

MKVtoolNIX changelog says:

2004-04-30  Moritz Bunkus  <moritz@bunkus.org>

* all: Increased the precision for timecodes in chapter files to
nanoseconds (optionally, you can still use fewer digits after the
'.').

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)

[®om]

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.

REALLY????

Can u copy-past me one of your cuesheet?

[kjoonlee]

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

[goldenear]

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! ;-)

[®om]

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

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)

This post has been edited by ®om: Jul 17 2004, 01:07

[taemun]

®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

[goldenear]

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)

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

[Pamel]

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)

....
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.

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.

[ChristianHJW]

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.

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. .....

[goldenear]

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

[Ariakis]

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.

[goldenear]

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.

[®om]

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

[Ariakis]

Another trick is to use the secret -z switch wich activate the debug mode and will display everything that's happening.

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"?

This post has been edited by Ariakis: Jul 18 2004, 05:01

[Omion]

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

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)

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:

CODE

(MKVInfo) |   + Start: 00:08:28.410000000 at 14766

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.

[goldenear]

Another trick is to use the secret -z switch wich activate the debug mode and will display everything that's happening.

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"?

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)

[kjoonlee]

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.

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

INDEX Command

Description:

This command is used to specify indexes (or subindexes) within a track.

 
Syntax:

INDEX <number> <mm:ss:ff>

Parameters:

number - Index number (0-99).
mm:ss:ff - Starting time in minutes, seconds, and frames (75 frames/second) . Note: All times are relative to the beginning of the current file.

This post has been edited by kjoonlee: Jul 18 2004, 19:14

[Omion]

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.

Cdrwin started it.

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

[mosu]

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

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)

Yes.

[mosu]

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

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