eac3to - audio conversion tool

[Shevek]

So, for playlists like this, until fully supported (if at all possible in future), should eac3to then report that this is a timed playlist and either refuse to work on it, or display an additional caveat to the user?

[Guest]

Originally Posted by madshi

I suppose that the playlist doesn't cover the whole 00000.m2ts

No, the BDInfo below shows that the referenced segments are contiguous:

00000.M2TS 0:00:00.000 0:01:31.991 0 0
00000.M2TS 0:01:31.991 0:08:43.856 0 0
00000.M2TS 0:10:15.848 0:10:26.092 0 0
00000.M2TS 0:20:41.940 0:00:43.243 0 0
00008.M2TS 0:21:25.183 0:00:00.333 0 0

The first time is the start time and the second is the duration. So, adding the duration to the start time gives the start time of the following segment.

It's possible that there is extra unreferenced material at the end of 00000.M2TS but it seems unlikely.

[madshi]

@neuron2, I've been told "eac3to 00000.m2ts+00008.m2ts" does not produce the expected runtime, so there *must* be extra unreferenced material at the end of either 00000.m2ts or 00008.m2ts. That's the only explanation that makes sense to me.

[Guest]

The other explanation is that the OP's estimate of the run time is wrong.

The only way to be sure is for the OP to give us the two M2TS files.

[XadoX]

They have around 3GB.

[madshi]

If the files as listed in the playlist had no extra material, we could calculate the overall runtime of [0+0+0+0+8] like this:

00000.m2ts: 0:21:25.183
00008.m2ts: 0:00:00.333

Overall runtime of [0+0+0+0+8] = 4 * 00:21:25.183 + 00:00:00.333 = 5141.065 seconds = 01:25:41.065

However, eac3to reported an overall runtime for [0+0+0+0+8] of exactly 01:30:00.000, so there must be some extra material somewhere, not referenced by the playlist.

[madshi]

@XadoX, what is the output of "eac3to 00000.m2ts" and "eac3to 00008.m2ts"?

[XadoX]

eac3to.exe f:\BDMV\STREAM\00000.m2ts
M2TS, 1 video track, 2 audio tracks, 1 subtitle track, 0:22:30, 60i /1.001
1: VC-1, 1080i60 /1.001 (16:9)
2: DTS, German, 2.0 channels, 384kbps, 48kHz
3: DTS, English, 2.0 channels, 384kbps, 48kHz
4: Subtitle (PGS), German

eac3to.exe f:\BDMV\STREAM\00008.m2ts
M2TS, 1 video track, 0:00:00
1: VC-1, 1080i60 /1.001 (16:9)

[madshi]

Yeah, so 00000.m2ts has about 1 extra minute of playback not referenced by the playlist.

[XadoX]

General
ID                                       : 0 (0x0)
Complete name                            : F:\BDMV\STREAM\00000.m2ts
Format                                   : BDAV
Format/Info                              : Blu-ray Video
File size                                : 2.93 GiB
Duration                                 : 23mn 0s
Overall bit rate mode                    : Variable
Overall bit rate                         : 18.2 Mbps
Maximum Overall bit rate                 : 48.0 Mbps

Video
ID                                       : 4113 (0x1011)
Menu ID                                  : 1 (0x1)
Format                                   : VC-1
Format profile                           : Advanced@L3
Codec ID                                 : 234
Duration                                 : 22mn 30s
Bit rate                                 : 16.7 Mbps
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 29.970 fps
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Interlaced
Scan order                               : Top Field First
Compression mode                         : Lossy
Bits/(Pixel*Frame)                       : 0.269
Stream size                              : 2.63 GiB (90%)

General
ID                                       : 0 (0x0)
Complete name                            : F:\BDMV\STREAM\00008.m2ts
Format                                   : BDAV
Format/Info                              : Blu-ray Video
File size                                : 54.0 KiB
Duration                                 : 270ms
Overall bit rate                         : 1 491 Kbps
Maximum Overall bit rate                 : 48.0 Mbps

Video
ID                                       : 4113 (0x1011)
Menu ID                                  : 1 (0x1)
Format                                   : VC-1
Format profile                           : Advanced@L3
Codec ID                                 : 234
Duration                                 : 334ms
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 29.970 fps
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Interlaced
Scan order                               : Top Field First
Compression mode                         : Lossy

[robertcollier4]

I have a question about the 24-bit-depth outputted by eac3to for use in lossy formats such as AAC which use floating point bit-depth. I am usually downmixing 6ch DTS files to 2ch AAC through piping to the qaac encoder. I am wondering if there would be better quality through having eac3to pass qaac its original 64-bit-depth file instead of a dithered 24-bit-depth file. I am trying to maintain best quality possible by doing as few bit-depth dithering operations as possible.

eac3to.exe "movie_6chdts.mkv" 2: stdout.wav -downDpl | qaac.exe --tvbr 127 --quality 2 --rate keep --ignorelength --no-delay - -o "2chaac.m4a"
eac3to tells me:
[a02] Reducing depth from 64 to 24 bits
[a02] Writing WAV

Even using the internally used neroaacenc does a down dithering operation. Why not pass the aac encoder the original 64-bit-depth data?
[a02] Reducing depth from 64 to 32 bits
[a02] Encoding AAC <1.00> with NeroAacEnc

I have read that lossy formats such as AAC use floating point and so while they do not technically have a "bit depth" they are able to deliver near equivalent of 64-bit-depth due to use of floating point. So in this case - wouldn't it better to have eac3to give qaac an undithered 64-bit-depth output so that qaac can encode the original undithered 64-bit-depth output from eac3to into floating point?

Reference: http://wiki.jriver.com/index.php/Audio_Bitdepth

Bitdepth of Lossy Formats
Lossy formats like MP3 [and AAC] use floating point math to build their output values. There is no true or correct bitdepth in this case.
Media Center preserves the full 64bit precision when converting from the lossy format to PCM and uses as much precision as possible during output.
In other words, taking a 16bit input file, encoding as MP3, and then playing it in Media Center will cause 64bit data to be delivered to the playback engine. This does not mean that the file has improved, only that Media Center does the best job possible dealing with the MP3 (or other lossy) data that is not inherently precise to some number of bits.

Reference: http://en.wikipedia.org/wiki/Talk%3AAudio_bit_depth

In a course on mastering that I took at Berklee College of Music, it was recommended that dither not be applied when lossy formats, like mp3 and AAC, were the destination. The reason being that dither to combat quantization is really only applicable to PCM because formats like mp3 do not really "quantize" in the same sense, especially if they are floating point.

Since eac3to operates internally in 64-bit-depth anyways, is there any way I can retain this and have eac3to give me its original 64-bit-depth wav as its output? (no dithering).

[nevcairiel]

Most encoders only accept up to 32-bit floating point ("float"), and not 64-bit ("double"), which is most likely why you're seeing the conversion for Nero.
If you think qaac supports 64-bit floating point input, you can use the "-full" switch, which lets eac3to output 64-bit float (or so i remember)

Note that most decoders also only produce 32-bit floating point (however eac3to might produce 64-bit after the downmixing)

[LigH]

An intermediate 64-bit result based on the decoding of an already lossy source, with even more loss due to the downmixing...

Will someone rather be able to hear the difference between 24 and 32 bit samples, or between original and lossy encoding instead? — Does he have a separate home cinema room with audiophile wall covers, or just a living room with furnitures?

And most important: Does he use gold-capped digital cables?

Get that steam out of here ...

[robertcollier4]

Originally Posted by nevcairiel

If you think qaac supports 64-bit floating point input, you can use the "-full" switch, which lets eac3to output 64-bit float (or so i remember)

Thank you nevcairiel - the -full switch is exactly what I was looking for. eac3to DPLII algorithm works internally with and outputs 64-bit-depth and so this is the best thing to pass to qaac compressor.

eac3to.exe "video_6chdts.mkv" 2: stdout.wav -downDpl -full | qaac.exe --tvbr 127 --quality 2 --rate keep --ignorelength --no-delay - -o "2chaac.m4a"

Works great. eac3to now no longer reduces bit-depth. And qaac accepts the 64-bit-depth piped input just fine and a down dithering operation was avoided. I prefer using qaac because it has a special "--no-delay" switch (otherwise neroaacenc adds an encoder delay of 44ms).

I recommend adding the -full switch to the documentation (I could not find it anywhere). Also I advise anyone piping to qaac to use the -full switch for better quality - down dithering operations make a difference and if it can be avoided with a simple switch it should be. The m4a filesize produced by qaac with the "eac3to -full" switch is also approx. same - it just feeds qaac a more accurate source for it to apply its compression to.

[filler56789]

@ madshi:

Originally Posted by tebasuna51

Info

- Document all the working parameters.

Did you miss that, or you just think it would be an "exceedingly-major" fix/improvement?

Originally Posted by robertcollier4

Thank you nevcairiel - the -full switch is exactly what I was looking for. eac3to DPLII algorithm works internally with and outputs 64-bit-depth and so this is the best thing to pass to qaac compressor.

[XadoX]

Originally Posted by madshi

Yeah, so 00000.m2ts has about 1 extra minute of playback not referenced by the playlist.

Any new ideas of a workaround?

[Guest]

Chop off the extra stuff using 'Output Trimmed TS' in DGIndexNV. Then load the trimmed 00000.m2ts and 00008.m2ts (if that 1/3 second of video is crucial!) in DGIndexNV and off you go.

Alternatively, trim out the extra material in your Avisynth script.

[XadoX]

Originally Posted by neuron2

Chop off the extra stuff using 'Output Trimmed TS' in DGIndexNV...

Thx I will use your workaround.

[frencher]

Originally Posted by frencher

Hi all and madshi,

I wanted to know if others have had the same problem as me for demuxing 3D Bluray PGS subtitles tracks (.sup) and if an update will fix this problem ?

Thanks

Sorry I do not understand English, are you fix ?
If I missed the topic that interests me here talking

[tebasuna51]

@frencher
About your question: "I wanted to know if others have had the same problem as me for demuxing 3D Bluray PGS subtitles tracks (.sup)"
Seems the answer is "Nope", at least not for me.

Please put the log file, if show any <ERROR> or <WARNING>, or more info about your problem.