Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Audio encoding

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 14th January 2009, 10:25   #7841  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by shanghai2004 View Post
[a03] Creating silent AC3 frame failed. <WARNING>
That's a bug, but it has no negative effect.

Quote:
Originally Posted by shanghai2004 View Post
Code:
[a03] Realizing (E-)AC3 gaps...
[a03] Creating file "e:\chicago - 3 - E-AC3, 5.1 channels, 3024kbps, 48khz.eac3"...
[a04] Starting 2nd pass...
[a04] Creating silent AC3 frame failed.  <WARNING>
[a04] Realizing (E-)AC3 gaps...
[a04] Creating file "e:\chicago - 4 - E-AC3, 2.0 channels, 448kbps, 48khz.eac3"...
Added fps value to MKV header.
eac3to processing took 39 minutes, 39 seconds.
Done.
The 2nd pass took less then a second, so was not done properly probably.
2nd pass processing can be very fast, depending on the circumstances. If eac3to says 2nd pass processing succeeded, then it most probably did.

Quote:
Originally Posted by ragboy View Post
I have a quick question. When I check a title, it shows the audio delay of a track, like say (7ms). When I transcode to AC3, it says it is applying the RAW/LPCM delay. Does this mean that I don't need to appy that 7ms when remuxing? Does eac3to apply that delay on transcoding, so I don't need to adjust when I mux?
That's right. eac3to already applies the delay for you. Generally when using eac3to you usually don't need to worry about delays. The only exception is when eac3to creates a file for you with "DELAY" in the file name. In that case eac3to was not able to apply the delay. But the usually only happens for TrueHD tracks.
madshi is offline  
Old 14th January 2009, 15:44   #7842  |  Link
rack04
Registered User
 
Join Date: Mar 2006
Posts: 1,538
When muxing raw h264 stream to mkv using eac3to it doesn't appear to include the "muxing mode" information in the container. Verified using mediainfo. I understand this isn't anything important, just thought I'd pass it along.

For example:

Raw h264 stream to mkv using mkvmerge:

Code:
Video
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.1
Format settings, CABAC           : Yes
Format settings, ReFrames        : 3 frames
Muxing mode                      : Container profile=Unknown@4.1
Codec ID                         : V_MPEG4/ISO/AVC
Duration                         : 1mn 59s
Bit rate                         : 3 182 Kbps
Nominal bit rate                 : 3 324 Kbps
Width                            : 1 280 pixels
Height                           : 688 pixels
Display aspect ratio             : 1.860
Frame rate                       : 23.976 fps
Resolution                       : 24 bits
Colorimetry                      : 4:2:0
Scan type                        : Progressive
Bits/(Pixel*Frame)               : 0.151
Writing library                  : x264 core 65 r1074M b6bb3d4
Raw h264 stream to mkv using eac3to:

Code:
Video
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.1
Format settings, CABAC           : Yes
Format settings, ReFrames        : 3 frames
Muxing mode                      : Container profile=Unknown@0.0
Codec ID                         : V_MPEG4/ISO/AVC
Duration                         : 1mn 59s
Bit rate                         : 3 181 Kbps
Nominal bit rate                 : 3 324 Kbps
Width                            : 1 280 pixels
Height                           : 688 pixels
Display aspect ratio             : 1.860
Frame rate                       : 23.976 fps
Resolution                       : 24 bits
Colorimetry                      : 4:2:0
Scan type                        : Progressive
Bits/(Pixel*Frame)               : 0.151
Writing library                  : x264 core 65 r1074M b6bb3d4
rack04 is offline  
Old 14th January 2009, 15:45   #7843  |  Link
Nullity
Registered User
 
Join Date: Mar 2007
Posts: 46
Quote:
Originally Posted by madshi View Post
That's right. eac3to already applies the delay for you. Generally when using eac3to you usually don't need to worry about delays. The only exception is when eac3to creates a file for you with "DELAY" in the file name. In that case eac3to was not able to apply the delay. But the usually only happens for TrueHD tracks.
But I thought eac3to could only apply delays in 32ms frames or "chunks"? So if his source audio stream had a delay of say +/- 7ms, what operation would be performed on that stream exactly? Would it not touch it, since 7ms is close to no delay, maybe only if it was +7? If -7, would it apply +32ms resulting in a final delay of +25ms? Are different audio types handled differently?

I have an HDDVD with an EAC3 track that has a delay of -1001ms. When I processed it (which was a few months ago, so an older version of eac3to, don't remember which), it said it took care of the delay, yet there is still a delay, just not -1001ms. I have not been able to tell exactly how much, but through trial and error, I have narrowed it down to somewhere around 100ms.

Could you please add a feature which always adds the correct delay amount to either the file name and/or the log, regardless of if it was processed or not? Even if eac3to was able to process the file correctly to a 0ms delay, that would still be helpful to see.
Nullity is offline  
Old 14th January 2009, 15:51   #7844  |  Link
rebkell
Registered User
 
Join Date: Oct 2006
Posts: 303
Quote:
Originally Posted by Nullity View Post
But I thought eac3to could only apply delays in 32ms frames or "chunks"? So if his source audio stream had a delay of say +/- 7ms, what operation would be performed on that stream exactly? Would it not touch it, since 7ms is close to no delay, maybe only if it was +7? If -7, would it apply +32ms resulting in a final delay of +25ms? Are different audio types handled differently?

I have an HDDVD with an EAC3 track that has a delay of -1001ms. When I processed it (which was a few months ago, so an older version of eac3to, don't remember which), it said it took care of the delay, yet there is still a delay, just not -1001ms. I have not been able to tell exactly how much, but through trial and error, I have narrowed it down to somewhere around 100ms.

Could you please add a feature which always adds the correct delay amount to either the file name and/or the log, regardless of if it was processed or not? Even if eac3to was able to process the file correctly to a 0ms delay, that would still be helpful to see.
32ms is the length of an AC3 sample @48KHz, the various audio samples vary in length, 48KHz aac is 21.3333ms in length, Madshi can tell you the others, a lot of them are in the thread somewhere. The delay will be gotten as close as is possible to the nearest sample size.

I think I read somewhere that about 16ms is as close as anyone can determine a/v sync, could be even bigger, anyone know what the number is?
rebkell is offline  
Old 14th January 2009, 15:57   #7845  |  Link
Chumbo
Registered User
 
Chumbo's Avatar
 
Join Date: Feb 2005
Posts: 585
Quote:
Originally Posted by madshi View Post
Ok, so what if you configured your DOS box to show black font and white background? If I then wanted to draw white text on a transparent background, it would be invisible. You see, I can't use your defaults and then try multi-colored text output, because the number of colors possible is very limited and there'd be high danger of me accidently using a color which is invisible on your specific background color. That's why I have to redo the whole color scheme. Or I could think of a specific set of foreground colors for every possible background color you could have possibly specified. But I won't go there...
Yep, that's pretty much a given, i.e., that your colors may not match what a user may have configured, but it's the deal in the DOS world. I understand that I may need to change them if you go that route which is why if you just reset after eac3to runs, that should be fine...and less of a headache for you.
__________________
Chumbo
Chumbo is offline  
Old 14th January 2009, 16:08   #7846  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by rack04 View Post
When muxing raw h264 stream to mkv using eac3to it doesn't appear to include the "muxing mode" information in the container. Verified using mediainfo. I understand this isn't anything important, just thought I'd pass it along.
I have no control over that, I think. I'm using Haali's Matroska Muxer to do the muxing.

Quote:
Originally Posted by Nullity View Post
But I thought eac3to could only apply delays in 32ms frames or "chunks"? So if his source audio stream had a delay of say +/- 7ms, what operation would be performed on that stream exactly? Would it not touch it, since 7ms is close to no delay
When doing pure AC3 demuxing, a delay of +/- 7ms would simply be ignored. No normal human could possible notice such a delay error, anyway. However, if the track is decoded, delay can be done on a per sample base, which means delay exactness can be done in "1/48" ms steps.

Quote:
Originally Posted by Nullity View Post
I have an HDDVD with an EAC3 track that has a delay of -1001ms. When I processed it (which was a few months ago, so an older version of eac3to, don't remember which), it said it took care of the delay, yet there is still a delay, just not -1001ms. I have not been able to tell exactly how much, but through trial and error, I have narrowed it down to somewhere around 100ms.
There's no way on earth eac3to would leave 100ms delay in the stream without telling you. I'd guess that either the HD DVD was authored badly, or that for whatever reason eac3to calculated a slightly incorrect delay value. Timestamps in HD DVD are less exact as with Blu-Ray, so it's more or a guess in HD DVD handling compared to Blu-Ray.

Quote:
Originally Posted by Nullity View Post
Could you please add a feature which always adds the correct delay amount to either the file name and/or the log, regardless of if it was processed or not? Even if eac3to was able to process the file correctly to a 0ms delay, that would still be helpful to see.
IMO the file names are long enough as they are. Also I don't want to get people confused. I can already see getting flooded with questions like "do I have to take care about the delay now or not?" and "how can I get rid of those remaining 7ms delay?" etc. No thanks...

Quote:
Originally Posted by rebkell View Post
I think I read somewhere that about 16ms is as close as anyone can determine a/v sync
Technically with Blu-Ray at least you can calculate delay very exactly, better than 1ms. But whether the studio really authored the disc that well is another question. I often notice that when I compare English vs. German audio tracks in a WAV editor, that they don't match exactly in sync. There are often a few ms difference (*not* caused by eac3to).

A normal human can see a delay mismatch of maybe 30-50ms if he's really good. Many people only see a mismatch of 100ms or bigger.

The best eac3to can do with bitstream audio is half an audio frame, which in the worst case is a raster of 16ms correction for AC3 tracks. All other audio tracks have smaller audio frames than that. So 16ms mismatch is worst case. And as I said, if you ask eac3to to decode/transcode audio, delay can be corrected in 1/48 ms steps.

Quote:
Originally Posted by Chumbo View Post
Yep, that's pretty much a given, i.e., that your colors may not match what a user may have configured, but it's the deal in the DOS world. I understand that I may need to change them if you go that route which is why if you just reset after eac3to runs, that should be fine...and less of a headache for you.
Ok, will see if I can make that work...
madshi is offline  
Old 14th January 2009, 16:48   #7847  |  Link
Nullity
Registered User
 
Join Date: Mar 2007
Posts: 46
Quote:
Originally Posted by madshi View Post
IMO the file names are long enough as they are. Also I don't want to get people confused. I can already see getting flooded with questions like "do I have to take care about the delay now or not?" and "how can I get rid of those remaining 7ms delay?" etc. No thanks...
Fair enough, but could you please add the remaining delay to the log output? For instance, if my source AC3 stream has a delay of -112ms, and eac3to corrects it to -16ms (+3 32ms frames), could that be added to the log somewhere so I know what value to use when I remux the streams? That would be extremely helpful. I, and probably most people, do not know the frame size of all stream types, so doing the math ourselves is not really feasible. In my example case, I know a -16ms delay is not much and might not even be detectable, but it would be beneficial to know this information. eac3to already has to do the calculations, I would think it would be incredibly easy to just append that value to the log output. Even if you have to add a little note next to it saying "It is not necessary to correct a delay less than XXms" so you don't get a bunch of questions.

Quote:
Originally Posted by madshi View Post
A normal human can see a delay mismatch of maybe 30-50ms if he's really good. Many people only see a mismatch of 100ms or bigger.
I am one of those people who are extremely sensitive to audio delays.

Last edited by Nullity; 14th January 2009 at 16:56.
Nullity is offline  
Old 14th January 2009, 17:24   #7848  |  Link
alc0re
Registered User
 
Join Date: Jun 2008
Posts: 91
question about the delay issue...is the delay only fixed if actual transcoding is done? what if there's a delay detected but I'm only extracting the ac3 or dts file? is the delay fixed on an extract only operation?
alc0re is offline  
Old 14th January 2009, 18:00   #7849  |  Link
ExSport
Registered User
 
Join Date: Jul 2002
Posts: 91
Hello all there
Please it is possible somehow to pipe eac3 with e.g. mkfifo or another way?
Many thanks for any info.
Also Madshi, thanks for great app
ExSport is offline  
Old 14th January 2009, 18:29   #7850  |  Link
Momber
Registered User
 
Join Date: Mar 2007
Posts: 217
Quote:
Originally Posted by madshi View Post
A normal human can see a delay mismatch of maybe 30-50ms if he's really good. Many people only see a mismatch of 100ms or bigger.
That's right. 70ms is the threshold for people without special training.
Momber is offline  
Old 14th January 2009, 19:13   #7851  |  Link
nautilus7
Registered User
 
nautilus7's Avatar
 
Join Date: Jan 2006
Location: Athens, Greece
Posts: 1,518
Quote:
Originally Posted by Nullity View Post
Fair enough, but could you please add the remaining delay to the log output? For instance, if my source AC3 stream has a delay of -112ms, and eac3to corrects it to -16ms (+3 32ms frames), could that be added to the log somewhere so I know what value to use when I remux the streams? That would be extremely helpful. I, and probably most people, do not know the frame size of all stream types, so doing the math ourselves is not really feasible. In my example case, I know a -16ms delay is not much and might not even be detectable, but it would be beneficial to know this information. eac3to already has to do the calculations, I would think it would be incredibly easy to just append that value to the log output. Even if you have to add a little note next to it saying "It is not necessary to correct a delay less than XXms" so you don't get a bunch of questions.
What movie is that?

(Sorry, if you already answered that to any of your previous posts)
nautilus7 is offline  
Old 14th January 2009, 19:26   #7852  |  Link
bmnot
Registered User
 
Join Date: Jun 2007
Posts: 215
What's the best way to redo 1088 mkvs I made long time ago with gdsmux? I wanna get rid of that gray line. Demux with mkvextractgui, then mux to mkv with eac3to, or mux to ts with tsmuxer and back to mkv with eac3to? or other?
bmnot is offline  
Old 14th January 2009, 20:01   #7853  |  Link
rebkell
Registered User
 
Join Date: Oct 2006
Posts: 303
Quote:
Originally Posted by Momber View Post
That's right. 70ms is the threshold for people without special training.
Not intending to hijack this thread, but it seems to be a main subject today, I found this interesting and it seems that we're much more acceptable of audio arriving after video than the other way around, we can see it before we hear it and it's not as distracting as hearing it then seeing it

Quote:
In 1998, ITU-R published BT.1359, recommending the relative timing of sound and vision for broadcasting. Studies by the ITU and others have suggested that the thresholds of timing detectability are about +45ms to -125ms, and the thresholds of acceptability are about +90ms to -185ms. (See Figure 1.)

Other research shows similar but not identical results — and being a function of human perception, we should expect the results to vary. The ATSC Implementation Subcommittee IS-191 has found that under all operational situations, the sound program should never lead the video program by more than 15ms and should never lag the video program by more than 45ms (±15ms). According to the IS, BT.1359 “was carefully considered and found inadequate for purposes of audio and video synchronization for DTV broadcasting.”
http://broadcastengineering.com/audi...ging_lip_sync/
rebkell is offline  
Old 15th January 2009, 00:06   #7854  |  Link
ggking7
Registered User
 
Join Date: Sep 2006
Posts: 249
I'm able to 'eac3to /mnt/cdrom' with a mounted Blu-Ray disc, but 'eac3to /mnt/cdrom 1)' doesn't work. Does that work for anyone else?
ggking7 is offline  
Old 15th January 2009, 00:57   #7855  |  Link
Nullity
Registered User
 
Join Date: Mar 2007
Posts: 46
Quote:
Originally Posted by nautilus7 View Post
What movie is that?

(Sorry, if you already answered that to any of your previous posts)
The post you quoted was just a made up example, but my original post asking about the -1001ms delay was from the King Kong HDDVD (US).
Nullity is offline  
Old 15th January 2009, 01:08   #7856  |  Link
nautilus7
Registered User
 
nautilus7's Avatar
 
Join Date: Jan 2006
Location: Athens, Greece
Posts: 1,518
I have King Kong HD DVD. I think it's the US version (was there a different one?). I'll test and report about sync.
nautilus7 is offline  
Old 15th January 2009, 05:41   #7857  |  Link
Momber
Registered User
 
Join Date: Mar 2007
Posts: 217
Quote:
Originally Posted by rebkell View Post
the thresholds of acceptability are about +90ms to -185ms.
Woooooaaah! Not to me they're not!
Momber is offline  
Old 15th January 2009, 06:05   #7858  |  Link
laserfan
Aging Video Hobbyist
 
Join Date: Dec 2004
Location: Off the Map
Posts: 2,461
Quote:
Originally Posted by Momber View Post
Woooooaaah! Not to me they're not!
Well then Momber you're obviously not "most people"!

(In fact I should probably add that many of the members here are not "most people" either!)
laserfan is offline  
Old 15th January 2009, 06:20   #7859  |  Link
Nullity
Registered User
 
Join Date: Mar 2007
Posts: 46
Quote:
Originally Posted by Momber View Post
Woooooaaah! Not to me they're not!
I'm with you man, that would drive me crazy too.
Nullity is offline  
Old 15th January 2009, 06:32   #7860  |  Link
rebkell
Registered User
 
Join Date: Oct 2006
Posts: 303
Quote:
Originally Posted by Nullity View Post
I'm with you man, that would drive me crazy too.
I agree completely, I would agree that the +15 to -45 would probably be acceptable, but no way would I not be irritated in a big way by nearly a tenth of a second early and nearly 2 tenths late.
rebkell is offline  
Closed Thread

Tags
eac3to

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 13:15.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.