View Full Version : Audio Stream detection problem
delphijos
18th December 2006, 11:55
If different audio streams in the "same position", only the last detected one is visible. I mean if there is az mpeg audio on $C0 pid ( first mpeg audio stream) and in the private stream contains an AC-3 stream on substream id $80 ( first AC-3 stream) only the AC-3 stream is detected. This also happens on second, third, etc..
"position"
The same thing happens if there is an AC-3 stream on substream $80 ( first AC-3 stream) and a PCM stream on substream $A0 ( first PCM stream). Every time, only the "latests" detected stream is visible if there are different streams in the "same position". Is there any way to solve this, or I did something wrong, or what can I do?
neuron2
18th December 2006, 14:44
What software tool are you talking about?
If you are talking about DGIndex, please upload a sample unprocessed source stream that I can examine. If you are saying that there are two or more audio streams on the same PID of a transport stream, well, I've never seen such a thing. Where did you get this stream?
delphijos
18th December 2006, 15:39
I'm talking about DGIndex. I'm talking about program streams. The "same position" means to me like this:
mpeg | AC-3 | DTS | PCM
C0 | 80 | 88 | A0
C1 | 81 | 89 | A1
C2 | 82 | 90 | A2
C3 | 83 | 91 | A3
C4 | 84 | 92 | A4
etc...
Of course, Ac-3, DTS, and PCM are substream ID's, these are in the private steam.
If an mpeg file contains an Mpeg stream at $C0 ( 1. audio track) you set first audio to MPEG.
Channel[MPA_Track] = FORMAT_MPA; // MPA_Track is 0 !
This OK. But if this movie contains AC-3 stream at $80 ( 1. AC-3 track )
Channel[This_Track] = FORMAT_AC3; //This_Track is 0 !
and the result is, only the AC-3 track is detected. And, if there is a PCM stream in this file on $A0 ( 1. PCM track )
Channel[This_Track] = FORMAT_LPCM; // This_Track is 0 !
In this case, the AC-3 stream also won't be detected.
Here http://rapidshare.com/files/7998029/test.mpg
is a test file. This contains four audio streams.
C0 -> Mpeg stream
80 -> AC-3
81 -> AC-3
82 -> AC-3
but DGIndex does not detect the mpeg stream.
neuron2
18th December 2006, 17:38
Where did you get this program stream?
delphijos
18th December 2006, 19:02
This file is multiplexed with TMpegEncoder. ( I made it for the test)
I made an ugly "solution" for the problem. I didn't have more time, s o I added a new command line parameter, then I can select that DGIndex search only for mpeg, AC-3, DTS, or PCM streams. So, if i run DGIndex and set to demux first audio stream on that test file with this new parameter set to 0 , then demux mpeg stream, new parameter set to 1 demux AC-3 stream.
I know it is far from perfect, but it is a solution for me.
Sorry for bothering you, I like DGIndex very much and I totally appreciate Your work. I wrote this only to inform you. I think the problem is that you counting the same variable for all different type of audio streams.
neuron2
18th December 2006, 20:19
The demuxing derives from DVD standards, where this collision never happens. Can't you start your AC3 substream numbering at 0x81 if you know that the MPA track will have a ID of 0?
delphijos
18th December 2006, 20:58
I know, thank you.
I'm afraid not. I'm using program stream mpegs, and the ID determine what is the language of the stream.
C0 -> English Mpeg
80 -> English AC3
88 -> English DTS
A0 -> English PCM etc...
neuron2
18th December 2006, 22:20
I'll see if I can modify DGIndex so that it avoids colliding on track numbers. Thank you pointing out this issue.
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.