regarding LWING_GAIN in matroska

[DSPguru]

LWING_GAIN is a comment with info of (linear) gain to be applied on playback time of audio.

originally, it was "born" as a solution for postgain assertion of vorbis streams (By storing the LWING_GAIN comment in the ogg/ogm). now i use the same method for applying postgain on aac (LWING_GAIN is stored as an mp4 comment).

question is -
if a user transmux ogm to mkv or mp4 to mkv --> does matroska preserve this tag ? does it has any effect on the playback volume ?
i believe it should.. :)

thanks,
Dg.

[Suiryc]

Hi

As far as Ogg Vorbis is concerned, we store the first 3 packets (i.e. header, comment and setup) as private codec data in the Matroska file.
So the LWING_GAIN comment (stored in the second packet) is kept and stored in the Matroska file.
During playback those codec private data are sent to the decoder (CoreVorbis here). Since CoreVorbis take into account the comments and understand this specific comment there shouldn't be problems.

But I dunno for AAC in MP4 ;)

[DSPguru]

i liked the Ogm solution. :)
now we need one for mp4!

[Animaniac]

Do players (namely Gabest's filter) adhere to the tag?

[bond]

Originally posted by DSPguru
now we need one for mp4perhaps you should contact the mp4 gurus menno and ivan dimkovic on hydrogenaudio about that...

[Suiryc]

Originally posted by Animaniac
Do players (namely Gabest's filter) adhere to the tag?
In the case of Ogg Vorbis this isn't necessary, the splitter filter (Matroska Splitter) get the headers from the Matroska file (as I said the second Packet contains this tag) and use it to setup the decoder (CoreVorbis), so at this point the splitter doesn't even know about this tag but the decoder (which is the one that has to handle it) received the tag.

[bond]

i talked to menno about postgain in aac/mp4 and there are two official possibilities to implement that:

1) in the aac stream itself by changing the global_gain bitsream element (which can cause quality issues as in aac "the scalefactors are tuned relative to each other to give the best possible quality, when changing only the globalgain these relative differences change")

2) in the mp4 container by using a volume element in the mp4 header (it's called "volume" and it's in the "mvhd" atom):
"volume is a fixed point 8.8 number that indicates the preferred playback volume. 1.0 (0x100) is full volume."
It should be easily possible to use the lwing_gain tag and the MP4 volume element in exactly the same way, but with the difference that the element is officially supported in the mp4 specs

[DSPguru]

i prefer updating a metadata tag (LWING or mvhd.volume) than changing the global_gain field on all frames. i agree with menno.
mvhd sounds like a better solution for mp4 than LWING, but probably irrelevant for ogm and mkv containers, isn't it ?

[ChristianHJW]

Hmmm .... we have an official replay gain EBML element in the matroska specs, maybe this could be used to preserve the info in LWING_GAIN in a more 'official' way, so the container also does know about the general 'loudness' of the track ? Is this possible at all ?

[DSPguru]

the only info supplied by BeSweet is the maxgain value, which is 1/replaygain's peak value.
if the matroska filters take this value in count on playback, the only open problem is pointing out a mp4->mkx transmuxing process that includes reading of the LWING_GAIN tag and writing the invert value as peak in the replaygain element.

[Chez_Wimpy]

Hmmm, to this point I had been generating replaygain tags in foobar2000, then muxing the HE-AAC mp4 files with video into matroska. Does this mean that replaygain tags are discarded during the process (I wouldn't know how to check)? Further, does the CoreAAC decoder even support replaygained mp4s? This was a great selling point of using vorbis for audio, post gain is a really useful feature.

-CTB

[[Toff]]

Originally posted by Chez_Wimpy
Hmmm, to this point I had been generating replaygain tags in foobar2000, then muxing the HE-AAC mp4 files with video into matroska.
Does this mean that replaygain tags are discarded during the process (I wouldn't know how to check)?

There is replaygain tag equivalent in matroska, but i don't think current tools automatically convert tag.

Originally posted by Chez_Wimpy
Further, does the CoreAAC decoder even support replaygained mp4s? This was a great selling point of using vorbis for audio, post gain is a really useful feature.
No there is no specific support for replaygained mp4s in CoreAAC. For that it will need a kind of interaction between the decoder and the mp4 splitter. The mp4 splitter will need to pass the replaygain info in some way as there are not in the aac bitstream.

[bond]

Originally posted by [Toff]
The mp4 splitter will need to pass the replaygain info in some way as there are not in the aac bitstream.i talked to shitowax (3ivx developer) about supporting the volume element in the 3ivx splitter and he said that he is willing to implement it if he knows that there are progs which use/change this value

so dspguru plz hurry up implementing postgain support for mp4s in besweet :)

btw. shitowax said that the splitter can also directly pass the volume info to the renderer so there is no need for an aac decoder to support this volume element

[DSPguru]

Originally posted by bond
so dspguru plz hurry up implementing postgain support for mp4s in besweet :)what's wrong with the current LWING_GAIN feature ?

btw. shitowax said that the splitter can also directly pass the volume info to the renderer so there is no need for an aac decoder to support this volume element hmm.. i don't understand the use of this feature ? (are you planning on storing decoded aac streams on mkv ?)

[bond]

Originally posted by DSPguru
what's wrong with the current LWING_GAIN feature ?nothing but i thought you wanted to use the mvhd.volume element in mp4 as this is officially supported in the mp4 specs...

hmm.. i don't understand the use of this feature ? (are you planning on storing decoded aac streams on mkv ?)nope, i talked about postgained aac streams in mp4 container
shitowax meant that the renderer is responsible for the output volume not the decoder and that the splitter can directly pass the volume value to the renderer

[DSPguru]

Originally posted by bond
nope, i talked about postgained aac streams in mp4 container
shitowax meant that the renderer is responsible for the output volume not the decoder and that the splitter can directly pass the volume value to the renderer that's very good (and recommended :)), but biggest challange is support in ogm and mkv.

[bond]

so are you planning to output mp4s with the mvhd.volume set, when people encode aac in besweet by using postgain?

i think it will not be very difficult to implement the reading out/parsing of this element and the "translation" to the container specific element in the exisitng matroska muxing tools

[DSPguru]

Originally posted by bond
so are you planning to output mp4s with the mvhd.volume set, when people encode aac in besweet by using postgain?no.

[bond]

sorry to hear that :(

if you start to work on implementing postgain for aac anytime you can use this element as shitowax is implementing support for that in the 3ivx splitter anyways

[DSPguru]

i don't have the time to read the mp4 specs and implement the mvhd.volume alternation, but i'm sure it would be as easy for shitowax to support the LWING_GAIN comment (if not easier) than supporting mvhd.volume .

anyway, the biggest challange, as said before, is dealing with the mp4 -> ogm/mkv transmux process. (and ogm/mkv, aac playback).

[shitowax]

If your LWING_GAIN is a simple comment(in the udta atom ?), you can't hope to have it supported on all mp4 platforms and it sounds that the mvhd.volume is the ISO way to proceed anyway ...

As far as I understand, you would like to transmux mp4->ogm/mkv and keep the volume attribute, right ? And do you use DirectShow to do that or some other libs ?

Originally posted by DSPguru
i don't have the time to read the mp4 specs and implement the mvhd.volume alternation, but i'm sure it would be as easy for shitowax to support the LWING_GAIN comment (if not easier) than supporting mvhd.volume .

anyway, the biggest challange, as said before, is dealing with the mp4 -> ogm/mkv transmux process. (and ogm/mkv, aac playback).

[DSPguru]

Originally posted by shitowax
If your LWING_GAIN is a simple comment(in the udta atom ?), you can't hope to have it supported on all mp4 platforms and it sounds that the mvhd.volume is the ISO way to proceed anyway ...yes, simple udta meta comment.
if you need a sample, you can easily make one. just add -ota( -hybridgain ) to your commandline.
perhaps bond can help you with that.. ;)
again, i don't have the time to read the mp4 specs and implement the mhvd.volume fiddling. if someone can supply a modest source-code that does this fiddling, i will add it to bsn.dll (which sources (http://dspguru.notrace.dk/plugins.html) are openned and released with bsd-like license)

BTW : i believe the best solution would be that Nero's aac.dll would write that mvhd.volume information. after all, aac.dll already includes a mp4 manipulation routines. for instance, it writes the nero comment (codec version, etc').

As far as I understand, you would like to transmux mp4->ogm/mkv and keep the volume attribute, right ? And do you use DirectShow to do that or some other libs ? as far as i know, there are two popular relevant transmux methods, both are directshow-based. the first uses graphedit with your filter, the second is nic's ogm_mux.
i agree that a general-purpose lib could avoid all directshow's limitations and just read the tag from one stream and write it to the other hand. this would be a reasonable solution. (easy to implement, but requires post processing - first your transmux, then you need to update tags).

[DSPguru]

Originally posted by DSPguru
if you need a sample, you can easily make one. just add -ota( -hybridgain ) to your commandline.
perhaps bond can help you with that.. ;)this is now even easier. you just need to select "hybridgain" in OagMachine.

[Kurtnoise]

thank you by the way DSP.....it's really a good tool :cool: It's work like a charm ;)