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

[flloyd]

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.

[goldenear]

flloyd, this has ever been discussed here
.

[Omion]

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

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

Works great for me. Thanks, Mosu!

[®om]

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

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

[®om]

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

This post has been edited by ®om: Jul 19 2004, 09:04

[mosu]

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

[®om]

Ah yes I've the 18h20 release

Where can I find the new ?

[goldenear]

Just redownload it from the mosu link

[®om]

This is always the 18h28 release

[goldenear]

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

[mosu]

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

[sPeziFisH]

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

mac.exe %2 %2.ape %1

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:

-i %s -s %o -y "%Y" -n "/a - /t" -e "C:\matrska\mac.bat" -o "-c3000" -x ".wav.ape" -m -f -z -w

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

[®om]

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

[sPeziFisH]

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

[koach]

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.

[DrDoogie]

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.

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

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?

[mosu]

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

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?

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

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

[mosu]

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?

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

[WarBird]

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

[DrDoogie]

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?

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

CODE

| + Writing application: mkvmerge v0.9.3 built on Jul 22 2004 22:32:01
| + Duration: 741.381s (00:12:21.381)
| + Date: Fri Jul 23 13:00:37 2004 UTC
| + Segment UID: 0x27 0x97 0x0e 0x9c 0x80 0xb5 0x9c 0x3c 0x02 0x76 0xe0 0xc2 0xed 0xac 0x00 0xaf
|+ Segment tracks
| + A track
|  + Track number: 1
|  + Track UID: 1837891533
|  + Track type: audio
|  + MinCache: 0
|  + Timecode scale: 1.000000
|  + Codec ID: A_FLAC
|  + CodecPrivate, length 1846
|  + Language: und
|  + Audio track
|   + Sampling frequency: 44100.000000
|   + Channels: 2
|   + Bit depth: 16
|  + Default flag: 1
|+ EbmlVoid (size: 1024)
|+ Chapters
| + Edition entry
|  + Chapter atom
|   + UID: 1128321519
|   + Start: 00:00:00.320000000
|   + Display
|    + String: Faithless_We Come 1
|    + Language: eng
|  + Chapter atom
|   + UID: 1175810377
|   + Start: 00:03:47.370000000
|   + Display
|    + String: Faithless_We Come 1 (Rollo & Sister Bliss Remix)
|    + Language: eng
|+ Cluster

CODE

PERFORMER "Faithless"
TITLE "We Come 1 (CD Single)"
FILE "CDImage.wav" WAVE
 TRACK 01 AUDIO
   TITLE "We Come 1"
   PERFORMER "Faithless"
   INDEX 00 00:00:00
   INDEX 01 00:00:32
 TRACK 02 AUDIO
   TITLE "We Come 1 (Rollo & Sister Bliss Remix)"
   PERFORMER "Faithless"
   INDEX 00 03:44:27
   INDEX 01 03:47:37

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

Do you mean 'INDEX 00' and 'INDEX 01'?

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.

[mosu]

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

CODE

PERFORMER "Faithless"
TITLE "We Come 1 (CD Single)"
FILE "CDImage.wav" WAVE
 TRACK 01 AUDIO
   TITLE "We Come 1"
   PERFORMER "Faithless"
   INDEX 00 00:00:00
   INDEX 01 00:00:32
 TRACK 02 AUDIO
   TITLE "We Come 1 (Rollo & Sister Bliss Remix)"
   PERFORMER "Faithless"
   INDEX 00 03:44:27
   INDEX 01 03:47:37

With your CUE sheet I get the following:

CODE

|  + Chapter atom
|   + UID: 2446882811
|   + Start: 00:00:00.426666666
|   + Display
|    + String: Faithless - We Come 1
|    + Language: eng
|   + Chapter atom
|    + UID: 159147718
|    + Start: 00:00:00.000000000
|    + Display
|     + String: INDEX 00
|     + Language: eng
|    + Hidden: 1
|   + Chapter atom
|    + UID: 2738600788
|    + Start: 00:00:00.426666666
|    + Display
|     + String: INDEX 01
|     + Language: eng
|    + Hidden: 1
|  + Chapter atom
|   + UID: 185174257
|   + Start: 00:03:47.493333333
|   + Display
|    + String: Faithless - We Come 1 (Rollo & Sister Bliss Remix)
|    + Language: eng
|   + Chapter atom                        
|    + UID: 4178430856
|    + Start: 00:03:44.360000000
|    + Display
|     + String: INDEX 00
|     + Language: eng
|    + Hidden: 1
|   + Chapter atom
|    + UID: 2671844136
|    + Start: 00:03:47.493333333
|    + Display
|     + String: INDEX 01
|     + Language: eng
|    + Hidden: 1

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.

[koach]

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?

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

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.

This post has been edited by koach: Jul 23 2004, 16:37

[goldenear]

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

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

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 )

This post has been edited by goldenear: Jul 25 2004, 22:31

[Omion]

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

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?

This post has been edited by Omion: Jul 24 2004, 01:02

[goldenear]

Might you mean MKAenc?

yep! (fixed)

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?

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.

This post has been edited by goldenear: Jul 24 2004, 01:24