EAC3TO Requests and General Discussion

[DelBoy83]

Hi Skull, don't worry the problem is now sorted.

[Curly]

Thank you, skull, for jumping in, and DelBoy83, glad to hear it's good for you. Rocky and me are kinda busy right now trying to find out why a user is getting illegal instructions with the DGDecodeNV_test2 build.

[Rocky]

The eac3to_mod account was removed at our request at doom9, due to moderator misconduct (publicly posting our private message and refusing to delete it). All support for our releases of eac3to will henceforth be solely conducted here. We do monitor the madshi bug tracker also, but prefer reports here as we cannot update the tracker, etc. Thank you.

[LauraPalmer]

Please change back the log filename. It's now "log.txt" everywhere. For Blu-ray discs, using -demux or -check created "00001 - Log.txt" for 00001.mpls, similar to chapter filename. Now it's log.txt, which I accidentally overwrote with another eac3to command. Even "eac3to -help" writes to log.txt now.

[Curly]

I propose to add the process PID to the log file name. That would guarantee that each run would be different and you wouldn't overwrite. As the log file contains the command line, you'll be able to disambiguate them. Would this be OK for you? If not, propose something. We're not going back to generating two log files, however.

You could get overwrites with the old way, too (execute same command with slightly different options). With the PID you would never overwrite.

[skull]

I also like PID or alternatively, a timestamp, e.g. log_200102.txt or log_20-01-02.txt indicating completion of eac3to process run @ 08:01:02PM.

[Curly]

Would need date and time, which would be long but possible. Let's see what OP prefers.

[Rocky]

Not much to gain from date/time, as the file has a creation time. I think PID is just fine, like DGDemux.

[jpsdr]

BTW, why was it changed ? What is the issue with the previous way, having the log file the same name than the file produced/extracted ?

Otherwise, i don't think also the date is very relevant, if previous way is not possible anymore, the PID is indeed a good thing.

[Curly]

It was changed to avoid generating the same log file twice and allow for it to follow the new destpath option. I chose one of the two to delete and it was the one you apparently prefer. I'm always looking to reduce complexity and that's what I did. Now we need to decide whether to restore the old way or use the PID way. If nobody throws a temper tantrum I'll do the PID way. I don't like the old way as commands without a source file weren't getting logged, except by the duplicate log file, which is not the greatest idea of all time IMHO. Also, with the old way you can still have overwrites, while with the PID way it is practically impossible.

[Curly]

I've released eac3to 3.50 using the PID concept to avoid overwrites. The notes file was augmented to include a description of log file operation.

Log File
--------

Log file generation was changed. Previously two identical copies of the log file
were generated in the directory where eac3to.exe was located. One of them was
called simply "log.txt", and the second was prefixed with an identifier related
to the first source file. If the command did not involve a source file, then only
the first one was generated.

Now, only one log file is generated. It is generated in the current directory, i.e.,
the directory you are in when you issue the eac3to command. This is typically the
same as the source file directory because you go to that directory to run eac3to,
but that may not be the case. It depends on how you or the 3rd-party application
that invokes eac3to operates.

The log file name is "logXXXX.txt", where the XXXX is the numerical PID number of
the eac3to command. Every command uses a different PID so this scheme completely
prevents overwriting of log files. Note that you can determine the creation date
and time of the log file by inspecting the file creation time.

[jpsdr]

Just out of curiosity, if i create a .bat file with the following commands:

Code: Select all

eac3to 00000.m2ts 2: J:\Audio_En.ac3
eac3to 00000.m2ts 3: J:\Audio_Fr.ac3

the 2 log files will have a different name, that's it ?

Personnaly, i don't often look at the log file, so it's more a "i was used to" situation than a "prefer" situation. It just surprised me to not see the log file next the result file in the directory, and noticed "what's this log.txt file is...?"
And of course, in my case, it was just the last result of all the commands in the .bat file.

Once again, thanks for your work on eac3to.

[Curly]

yeah pretty much
its gud 2 surprise people once in a while
they get really surprised when I bark at them
woof

[LauraPalmer]

Thank you! Using process PID or time, all are fine by me, as long as I don't easily overwrite them. Best option, in my opinion, would be to combine PID/time with previous filename (to make searching for the right log easier). I'd personally disable logging of error/help messages, but that's not a big deal at all.

[Curly]

You're welcome, Laura. Thank you for the feedback and I'm glad you are OK with the way I did it.

[w0bble]

Thank you so much for continuing the development of eac3to! I do have a couple of requests / reports of unwanted behavior.

First, there's now a log created for every single run of eac3to even if you're just reading a disc/playlist/file to see what's there so you can end up with a lot of log files to sift through. Previously, there was only a log when eac3to actually did something. Could this be rolled back?

Secondly, and kind of related. When not using/setting -fast simply reading a disc/playlist/file is really slow. Could commands that don't involve any sort of processing imply -fast? That was the older behavior as well.

Thank you

[Curly]

I understand the concern with accumulation of log files. I'm not going to revert to old behavior but maybe we can mitigate it for you. How about if I keep only the last N logfiles, where N could be a fixed number like 5 or 10, or maybe it could be configurable.

-fast is new with our builds. So your comment about default behavior of the old version being fast is incoherent. In my testing -fast doesn't make a huge difference. What you are probably seeing is just slow behavior when there are a lot of M2TS files in a playlist, etc.

Welcome to the forum.

[Curly]

I have it working to keep only the 5 most recent logs in any given directory. I'll make a release shortly.

[w0bble]

I think what happened is I had a lot of sporadic I/O and CPU activity so it seemed like -normal and -fast were making a big difference when reading a playlist ("eac3to path\to\disc 1)"). In fact there's no difference at all? Oops.

I have it working to keep only the 5 most recent logs in any given directory. I'll make a release shortly.

I'd rather have the log spam myself. Better that than risk losing some I want to reference.

[Curly]

I'd rather have the log spam myself. Better that than risk losing some I want to reference.

Then you should have answered me when I made the proposal (4 days ago!), not waited until I implemented it. So now you're stuck with it.

We hate hit-and-run posters here. Look, we reply to things very quickly so stick around until you get an answer.

[neto_pir]

Hello

I know that now you only get one Log file, but what if I want to get them for certain files: Chapters, 1 Audio and 5 Subtitles. I tested using the old method but I get errors.

Code: Select all

C:\BRtools\eac3to\eac3to.exe  "Path\to\BR-folder" 3) 1: "Path\to\Remux\[1]_Chapters.txt" -Log=Path\to\Remux\[1]_Chapters - Log.txt
Command line parameter "" is unknown.

C:\BRtools\eac3to\eac3to.exe  "Path\to\BR-folder" 3) 1: "Path\to\Remux\[1]_Chapters.txt" "-Log=Path\to\Remux\[1]_Chapters - Log.txt"
Command line parameter "Log=Path\to\Remux\[1]_Chapters - Log.txt" is unknown.

Am I doing something wrong.

Greetings

[Curly]

Hello neto_pir! Try this:

eac3to.exe "Path\to\BR-folder" 3) 1: "Path\to\Remux\[1]_Chapters.txt" -log="Path\to\Remux\[1]_Chapters - Log.txt"

BTW, guys, log files created with the -log file option will not be automatically deleted unless they begin with "log" and end with ".txt".

[neto_pir]

Hello

Thanks for the help, just like you put the quotes it worked.

Greetings

[Curly]

My pleasure, sir!

[Birb]

Hi,

I hope you're well. Sorry to be late to the party, I just found out about this forum. Is there a way to disable log files? After a eac3to run I just scroll through the cmd window. If it's all green I move on, if there's an error I look into it. No need for log files ever for me.

How about if I keep only the last N logfiles, where N could be a fixed number like 5 or 10, or maybe it could be configurable.

This was a good idea, and if N was 0 it'd completely disable log files. But even simpler would be a -nolog switch in the .ini to just disable logging.


And now that we're here, something else that has always bothered me since the dawn of time. It's the chapters taking the 1: spot on the list of tracks. I extract from mpls and m2ts alike and every time I set the tracks I have to put special care if the item has chapters or not. If no chapters 1: is the video track, 2: the first audio, and so on. If there's chapters the video moves to 2: and the first audio moves to 3:

Mpls can or can not have chapters. M2ts don't, but sometimes when pointing to a m2ts it seems eac3to pulls the playlist from the mpls that references it and it wrecks my nerves (not always). If I move that m2ts away from the BDMV/STREAM folder the "link" is broken and I don't get the chapters.

All this to say: Can chapters be moved away from the 1: position as to not wreck havoc with the video/audio/subs list order? For example, this is when looking at a mpls:

Code: Select all

1: Chapters, 21 chapters
2: h264/AVC, 1080p24/1.001 (16:9)
3: AC3, Italian, 2.0 channels, 224kbps, 48kHz, dialnorm: -27dB
4: AC3, Italian, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
5: DTS Master Audio, Italian, 5.1 channels, 16 bits, 48kHz, dialnorm: 0dB
   (core: DTS, 5.1 channels, 1509kbps, 48kHz, dialnorm: 0dB)
6: AC3, English, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
7: DTS Master Audio, English, 5.1 channels, 16 bits, 48kHz, dialnorm: 0dB
   (core: DTS, 5.1 channels, 1509kbps, 48kHz, dialnorm: 0dB)
8: Subtitle (PGS), Italian
9: Subtitle (PGS), Italian

This when looking at a m2ts:

Code: Select all

1: h264/AVC, 1080p24/1.001 (16:9)
2: AC3, 2.0 channels, 224kbps, 48kHz, dialnorm: -27dB
3: AC3, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
4: DTS Master Audio, 5.1 channels, 16 bits, 48kHz, dialnorm: 0dB
   (core: DTS, 5.1 channels, 1509kbps, 48kHz, dialnorm: 0dB)
5: AC3, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
6: DTS Master Audio, 5.1 channels, 16 bits, 48kHz, dialnorm: 0dB
   (core: DTS, 5.1 channels, 1509kbps, 48kHz, dialnorm: 0dB)
7: Subtitle (PGS)
8: Subtitle (PGS)

See the offset? When working with a bunch of discs with a mixture of mpls/m2ts to process selecting the numbers for the tracks I want becomes a pain in the ass. Since chapters are not really a "track" imo they should have a special selector. Maybe 0: or C:. So a mpls becomes:

Code: Select all

0: Chapters, 21 chapters
1: h264/AVC, 1080p24/1.001 (16:9)
2: AC3, Italian, 2.0 channels, 224kbps, 48kHz, dialnorm: -27dB
3: AC3, Italian, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
4: DTS Master Audio, Italian, 5.1 channels, 16 bits, 48kHz, dialnorm: 0dB
   (core: DTS, 5.1 channels, 1509kbps, 48kHz, dialnorm: 0dB)
5: AC3, English, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB
6: DTS Master Audio, English, 5.1 channels, 16 bits, 48kHz, dialnorm: 0dB
   (core: DTS, 5.1 channels, 1509kbps, 48kHz, dialnorm: 0dB)
7: Subtitle (PGS), Italian
8: Subtitle (PGS), Italian

Now, the video tracks always will fall on 1:, first audio on 2:, and so on. Picking the tracks would be a breeze without taking into account the chapters slot offsetting the rest.

Well, sorry for the long ass post. Just my 2 cents.