• 1
  • 43
  • 44
  • 45(current)
  • 46
  • 47
  • 59
Testing audio engine ActiveAE
It was explained to me that XBMC expects to receive the audio packet within 100ms of the video packet, VLC obviously use a higher value of 200ms or above so it's more tolerant to this mismatch in video & audio timing.
Reply
(2013-12-15, 23:48)fritsch Wrote: Oki, we thought again a bit over it, current PR is here: https://github.com/xbmc/xbmc/pull/3838

Basically I removed it from the Sink to handle it especially before building channel map. Btw. which Encoder do you use to produce the 7.1 AAC files?

I am using the neor aac codec (free) in combination with eac3to.
I will test the newest build on Friday when I am at home again.
Reply
Yes, we already know. Your nero aac codec is not standard conform and this is all the problem we have.
http://git.videolan.org/?p=ffmpeg.git;a=...38f298d5ae

Anssi has picked it up and "workarounded that broken stuff" upstream. He will backport the commit to our xbmc.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
Hmm... well, after searching quite a bit on various forums... it's turns out that I'm not the only one with this problem. And this exact same thing has been reported way back in 2011... on XBMC Dharma : LINK to thread. The member seems to be having the exact same issue as me. My problematic files are also rips from my Criterion Blu-Rays that have a Mono LPCM audio.

There is also mention of this on Mede8er's forums - which (I think!) also uses an interface branching out from XBMC : LINK to thread.

Is there a way I can change anything (some pref files? remux the files a different way?) to fix this timing anomaly? Or is this something that I can request the devs to consider for an update to XBMC itself?

I truly thank everyone for their help till now.
Reply
It maybe possible to change XBMC to be more tolerant, but the better solution would probably be to generate files with correct timestamps I assume, in which case you might be better off visiting the MakeMKV forum and point out to the developer that for mono LPCM tracks it's applying a 200ms offset, since everyone who has problems is using MakeMKV so better to fix at the source.

You could also try the advice in that Mede8er thread and remux mkv with mkvmerge.
Reply
FernetMenta/fritsch, is there anyway to transcode mono LPCM to AC3 in ActiveAE? That XBMC Dharma thread linked to by sarvajanik mentions encoding to AC3 fixes the problem.
Reply
(2013-12-19, 14:48)jjd-uk Wrote: You could also try the advice in that Mede8er thread and remux mkv with mkvmerge.

I actually did try that. But no change. Is there another way I can (perhaps manually) fix the timestamp?

Will post on MakeMKV's forums as well. Thanks jjd-uk.
Reply
@sarvajanik

just out of curiosity have you tried to use eac3to to demux and then remux with mkvmerge rather than use makemkv? might be worth a shot.
Reply
(2013-12-19, 14:57)jjd-uk Wrote: FernetMenta/fritsch, is there anyway to transcode mono LPCM to AC3 in ActiveAE? That XBMC Dharma thread linked to by sarvajanik mentions encoding to AC3 fixes the problem.

At that point in the chain where the problem occurs it does not matter if the stream is mono or whatever. The raw packet as we read it from the file has a timestamp with this large offset.

EDIT: This is some stages before the data finally hit the audio engine.
Reply
@jjd-uk does it have to be eac3to & mkvmerge? Or can I use iMKVextract & MKVToolNix? Cause I'm more of a Mac person. The only reason I'm running XBMC on Windows is so that I can bitstream audio out to my receiver. Will try extracting the LPCM file first and then remuxing it back using MKVToolnix and let you know if that works.

I've reached out to the MakeMKV forum as well. Lets hope the moderator approves my post and we get some answers.

Thanks again.
Reply
(2013-12-20, 06:54)sarvajanik Wrote: @jjd-uk does it have to be eac3to & mkvmerge? Or can I use iMKVextract & MKVToolNix? Cause I'm more of a Mac person. The only reason I'm running XBMC on Windows is so that I can bitstream audio out to my receiver. Will try extracting the LPCM file first and then remuxing it back using MKVToolnix and let you know if that works.

I've reached out to the MakeMKV forum as well. Lets hope the moderator approves my post and we get some answers.

Thanks again.

i assume this is directed at me. imkvextract will only give you the streams from what makemkv made in the first place. the reason i suggested eac3to is to try pulling the streams from the source again with a different tool. i noticed that both you and the person in that dharma thread were using makemkv so i thought it might be worth seeing if the problem might be resolved with a different tool.
Reply
Hello. I speak for MakeMKV developers.

I believe the problem is how lacing frames are handled. In MKV audio tracks usually use lacing - several frames are packed together in a single block in order to save metadata overhead. Matroska spec doesn't regulate the maximum size per lacing block. mkvtoolnix has a hardcoded limit of 8 frames per block, while MakeMKV can produce much longer runs, up to 180 frames per block, limiting the block duration at 0.1 sec. Could it be that the splitter has an optimization that reads entire lacing block as a single packet when handling LPCM streams, as opposed to (correct) splitting a lacing block into hunderds of frames? If yes, then splitter could output a very long frames, and we could see the timecode drift up to 100 ms. Still, nowere near the reported 200ms though. The long lacing runs is the only problem I can think on top of my head. I've requested additional information on our forum.
Reply
Well getting back to my Blu-rays would take time. They're ~6000 miles away at home :'(

I'm working towards getting the info Mike has asked me for over at the MakeMKV forums' thread HERE.
Reply
Why don't you use double floating-point processing of audio ?

In the future, is it possible to have an audio calibration using REW , Room EQ Wizard Room Acoustics Software ?
Reply
PR Welcome. If you do it, we all might get it. There is absolutely no plan of us into that direction.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
  • 1
  • 43
  • 44
  • 45(current)
  • 46
  • 47
  • 59

Logout Mark Read Team Forum Stats Members Help
Testing audio engine ActiveAE1