Audio Broken since Dev 23.11.02.1

[Selur]

Mediainfo should be able to read the headers of most formats, but it only reads the first headers, it does not analyze the whole streams.
(depending on the mediainfo version reading raw data formats sometimes fails)
'ffinfo ...' or 'ffmpeg -i ...' also should work for most formats.

If you use fffmpeg/libav libraries together with audacity it should also be able to handle most common audio formats.

Cu Selur

[ToiletDuck]

Mediainfo should be able to read the headers of most formats, but it only reads the first headers, it does not analyze the whole streams.
(depending on the mediainfo version reading raw data formats sometimes fails)
'ffinfo ...' or 'ffmpeg -i ...' also should work for most formats.

If you use fffmpeg/libav libraries together with audacity it should also be able to handle most common audio formats.

Cu Selur

thanks for the info, will try that.. not that i need to do it , but it could be usefull in the future..

cheers,

[PizzaTime]

Following this thread.
This sounds like a similar or same issue I'm having. Although, as far as containers are concerned, I'm going from .avi to .avi, while deinterlacing it for intermediary work. It's weird because I didn't run into any sync issues until recently. I've tried quite a few of the solutions mentioned here and similar threads too. I am also using the dev version.

I'm not at my computer right now, but when you mention using ffmpeg instead of tsMuxer, are you referring to the settings under containers>other and then (un)selecting that checkbox? If so, I tried that and had no luck with my sync issues. I would have to grab a debug report though when I get home. But I wanted to check if that's what you were referring to.

[Selur]

This sounds like a similar or same issue I'm having. Although, as far as containers are concerned, I'm going from .avi to .avi, while deinterlacing it for intermediary work.

I doubt it, this only happens if:
a. m2ts/ts is the source
b. tsMuxeR is used for extraction.

If you can reproduce the problem, create a thread, share a debug output and other relevant info. (see sticky)
Maybe I can see something in the debug output, without knowing anything about the used formats and commands I will not start guessing.

Cu Selur

[PizzaTime]

Sounds good. I'll try and do that tonight when I get home.

[ToiletDuck]

This sounds like a similar or same issue I'm having. Although, as far as containers are concerned, I'm going from .avi to .avi, while deinterlacing it for intermediary work.

I doubt it, this only happens if:
a. m2ts/ts is the source

Cu Selur

Erm.. if my memory is correct..  i have had a mux crash using mkv as a source aswell in the past.. 
I have to double check that , to be sure.  But iam 99% sure of this ↑

But , we all agree that this only happends with media files containing Truehd Atmos tracks ... and if iam not mistaken a few with E-AC3 tracks !

But EAC3 seems to work just fine now, using the latest nightly build of tsmuxer.


cheers,

[Selur]

The question is not whether there was an issue with version xy question is always whether the problem is still present in the current version.
Debug outputs of old version do not really help.
I got a few ideas where the current problem is, but I won't spend again hours trying to explain to you what and how to test.
Since you mentioned that this does only occur with your source and not with some cuts of it, this might just be a problem with that source. (which could be a side product of attempts to circumvent copy protections)
-> Unless I can reproduce the tsMuxeR issue, I won't look further into it.

Cu Selur

[ToiletDuck]

The question is not whether there was an issue with version xy question is always whether the problem is still present in the current version.
Debug outputs of old version do not really help.
I got a few ideas where the current problem is, but I won't spend again hours trying to explain to you what and how to test.
Since you mentioned that this does only occur with your source and not with some cuts of it, this might just be a problem with that source. (which could be a side product of attempts to circumvent copy protections)
-> Unless I can reproduce the tsMuxeR issue, I won't look further into it.

Cu Selur

You should always assume that the problem occurred with the latest version of hybrid.
otherwise there really isn't much point in addressing this problem! That's only logical.

Also, let's not go there about who does more and how than others..
We / Users of software spends as much time if not more than developers to adress issue's, by trial and error.

The important thing to remember = is that we all keep working towards an sollution to best the of our abilities.


cheers,

[ToiletDuck]

Update:

I'v tested another bluray containing the very same Truehd Atmos track, to see if it would reproduce the same crash during muxing with tsmux.

And i like to report that tsmux through hybrid did an succesfull mux from start to end..

Interesting thing to note is, when comparing the source with the new source, the meta data from in hybrid and tsmuxergui seems to be identical and is read "correct" this time and is reported as → A_MLP and not as A_AC3 ...  

However, mediainfo reads the audio track as MLP_FBAAC-3 ..
Could it be that the A in A_MLP stands for the AAC3 ?

I'll check the other problematic source for copy protection left overs, and see if that has anything to do with the bad mux process ...
but then again, if a bad rip (copy protection) was the case, that should be reflected during playback.. Wich is just fine.


EDIT:

Just did a new BDrip, and the same thing happend.. according to hybrid the audio track is A_AC3 but in tsmuxgui the "partial" (because of crash) created new source, is identified as A_MLP..


cheers,

[Selur]

I'v tested another bluray containing the very same Truehd Atmos track, to see if it would reproduce the same crash during muxing with tsmux.

Okay, that reinforces my standpoint, that I won't look at it further until I get a source sample which allows reproducing the issue.

Cu Selur