Non audio data exceeds 100 mb in audio wav dd 5.1

[piotr_kast]

It's very stange problem. When I extract eac3 dd 5.1 track from movie (lenght movie aprox 2,5 hours), converted it to wav 5.1 track (in eac3to 3.27), and tried to read this file in Audition CS6 - I 've got message "Non audio data exceeds 100 mb and cannot be read". Reading this file in audacity 2.0.6 I've got whole file correct, but lenght on this file is approx. about 1 minute longer than lenght original eac3 files. What strange in this file: audio data was stretched to fill new lenght of file. When I tried convert whole movie to mpeg-2 DVD compilant file with tmpeg 5 wideo mastering works first part movie to approx. 1h 08 minut had audible audio, but the rest of file was silence.

Only option left to me and use this audio, is  split this movie to 1h parts. When i do this, and converted this eac3 files to vav files - Audition CS6 reads this files corectly.

video in this files was h264, 1080i50 and eac3to during in middle convertion in eac3 file says that converted eac3 file was not clean.

What the heck is going on? I tried different conversion settings in eac3to_more_gui, but this effect still persist.

[piotr_kast]

Add to previous message. My procedure not working. I cannot properly mix final file. Audio and video still have different lenght and i have a/v asynchron at the end of the mixed file.

[Djfe]

sounds like timing issues to me
Transportstreams use strict timing to keep things in sync despite errors that might happen in the data transfer process
(the transport way over a satellite is prone to errors)

the TSD can correct such files and fix timecodes.

If you have used it already to fix the stream, then remuxing might optimize it further

a log file would be definitely helpful here to see whether the TSD finds any issues while fixing the file


Other tools might be better in converting eac3 to wave (better error correction). Sounds strange to me that the sound was stretched.


Maybe someone else here has an idea what could be going on.

[Cypheros]

You are right Djfe, the steps to success should be:

Open with TS-Doctor and "Save to new file" to cut and/or fix file
Open new file with TS Demuxer (Tools/Expert Tools) to Demux and repair DD tracks timing

[piotr_kast]

Djfe, has right. This is definitively timecode errors.

Additionally when I played this file in DVBT decoder in the middle of the film decoder suddenly jump from DD 5.1 track to another. Propably in this place is sound drop-out.

Cypheros, I tried what you suggested. Everything was fine until I tried mux final audio track with original demuxed video track. Then suddenly turn out that I had 5 sec async in plus audio to video. But lenght audio had a few (up to 10 samples more) than video.

In addition Polish TV change order surround channels. In original file was now:SL, LFE, L, R, C, SR instead of: L, R, C, LFE, Ls, Rs. TS Doctor not correct order of this channels. But software converting sound places this channels in the right order. So this is not at all a problem for me.

No matter what I tried, I cannot properly generate mp4 files. Problem with timecodes occurs also in mpeg audio (but this happens only rarely - from time to time), but this I can fix with my other programs.

In attached file to this post:
section Test.txt - this files contain all logs from any program which I used to my conversion (this is file more to me than to you - in this way i wanted to remember what i do when convert video files)
Two other sections are logs from demuxing saved as new file to elementary streams

[Djfe]

you probably need to reencode the whole file, so that you get a consistant audio stream that is still aligned to the video stream and maybe contains silence during the channel switch


you could do it with Handbrake but might loose channels because of that (it doesn't recognize channel changes)

I don't know any good way of retrieving good timing after demuxing



I don't think that the TSD could simply change the channel order because that needs a reencode
the TSD only works on the packets layer of the transport stream
the independent streams are divided into packets that the TSD can modify, fix or delete (cutting)

[piotr_kast]

Dfje,

I tried your suggestion, but it not working too...

Demuxed audio after your suggested method was only 1h 08 minute lenght. I hope that cypheros repair this errors in ts streams. Now I was out of my new ideas how to fix this errors.

[Djfe]

Dfje,

I tried your suggestion, but it not working too...

Demuxed audio after your suggested method was only 1h 08 minute lenght. I hope that cypheros repair this errors in ts streams. Now I was out of my new ideas how to fix this errors.

Try to read again what I said:
I said that demuxing is not going to work well since the used tools seem to have issues reading the file correctly

You need to reencode the transport stream as a whole using tools like Handbrake to a container like mkv and then demux that container
(if you want to keep the original videostream then muxing the old video stream and the new audio stream might work, but it might also cause desync,
anyways the new mkv file shouldn't have any asynchronicity though)

@Cypheros pls take a look at his logs

the demuxer repeats lots of the eac3 frames to fill the silence (there is a few minutes without sound and the demuxer tries to keep audio and video in sync), this makes the sound track longer
if you reencode the file then the reencoder will encode it so that the encoded file will exactly play like the source one


do you have a fix log btw.? (not the demuxing one but the one generated if you fix a transportstream)

[piotr_kast]

When I open problematic file and save it to a new file I'll get tis file log:

01:37:48.262 ; 00:00:00.805 ; 13
01:38:31.955 ; 00:00:00.295 ; 9
01:44:46.489 ; 00:00:00.000 ; 2
01:53:11.130 ; 00:00:00.000 ; 3
01:54:18.649 ; 00:00:00.000 ; 2
02:19:59.020 ; 00:00:00.000 ; 5
02:49:42.453 ; 00:00:00.000 ; 7

Sorry I didn't understand you what you said in 16 hours today  Next your post is clear to me. I noticed you what happened when tried your later suggestion.

[piotr_kast]

Hello! Anybody home in Cypheros?

[Djfe]

that's not the log, that's the file_name_problem.txt
I'm talking about the file_name.log file

maybe you need to activate it's generation in the settings (general tab)

[Cypheros]

MUXOPT --no-pcr-on-video-pid --new-audio-pes --vbr  --vbv-len=500
V_MPEG4/ISO/AVC, "F:\Film\Informator 10_42 2 track eng 1_04 jump eng track_PID_00CA_.264", insertSEI, contSPS
A_MP3, "F:\Film\Informator 10_42 2 track eng 1_04 jump eng track_PID_00CB_.mp2"
A_AC3, "F:\Film\Informator 10_42 2 track eng 1_04 jump eng track_PID_00CC_.eac3"
A_AC3, "F:\Film\Informator 10_42 2 track eng 1_04 jump eng track_PID_00D0_.eac3"

Informator_Demux.log
Broadcast standard selected: DVB
Broadcast standard detected: DVB
PES WARNING: PID 00CC DataAlignmentIndicator = 0
PES WARNING: PID 00D0 DataAlignmentIndicator = 0

That could be the problem. The audio stream are not aligned. That means, the beginning of a PES packet is not the beginning of a EAC3 packet. As TS-Doctor is cutting on packet level, there is an overlapping for not aligned streams where the cutting happens, that's creating errors. As long as you stay with TS formating, there should be no problem because of the timestamps but most of the converters will fail if you  try to convert such files because most of them ignoring the timestamps.

[piotr_kast]

Djfe,
Mea culpa, I don't use this program with options others than default. I don't want to much mess with settings this program, because in the begining use of this program I had big problem with accidentally turning on function, which I cannot turn off later. Only full reinstalling helps.

OK. This option is now turning on. In attachment you have a log you requested.

I still testing way to ommit the problem. I working on this streams separately. I didn't use handbrake. Converting is no problem - it's easy part. But I had big problem on Windows 7 64bit demux this file creating in handbrake.

I had right reencode audio stream, but I still working on reencoding video.

At 01.40: I prepeared first 15 seconds of this file (included all streams - generated by "Save new file").

[Djfe]

you should definitely take a look at the settings, they are useful to configure the program to your needs
the default settings might not be the best settings for everyone (at least I configure stuff to my needs)

I don't know how you even managed to reset the settings through a reinstall
normally they survive a reinstall except if you delete the registry keys containing them


WOW! those are a lot of sync_errors in your file
your receiver seems to be a cheap one or your usb stick/hard drive isn't fast enough and can't keep up with the writing speed, I don't know

but what I can say is that this stream is far from perfect
you might consider a receiver change in the future (if other forum members agree with me on that)

[Derrick]

..too many errors. You'd better delete this file