Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Audio encoding

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 11th October 2015, 14:40   #13541  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,197
cant you just batch edit/delay/cut the logos with eac3to? would that add 16-bit audio delay or 24-bit for a DTS-HD MA track?
__________________
Laptop Lenovo Legion 5 17IMH05: i5-10300H, 16 GB Ram, NVIDIA GTX 1650 Ti (+ Intel UHD 630), Windows 10 x64, madVR (x64), MPC-HC (x64), LAV Filter (x64), XySubfilter (x64) (K-lite codec pack)
Thunderbolt8 is offline  
Old 11th October 2015, 14:57   #13542  |  Link
ndjamena
Registered User
 
Join Date: Sep 2012
Posts: 366
Yes, but I'd have to identify them properly first. The first episode of season 1 seems to start with 24 bit at the beginning of the end credits, but the last episode of the season starts at the logos.

This is the output for Pacific Rim:

F:\Make\Movies\ZZZ\Pacific Rim.wav
68: 00:00:00.000000000 - 8363: 00:00:00.009600694

Pacific Rim has 16 bit sound. It's from 2013... it's a 3D IMAX American Blockbuster science fiction film... and it has 16 bit sound. A little over 8000 bytes in the first 10 milliseconds is it's only claim to 24ness. I'm pretty sure I can just use the -dontDither switch on that, unless someone can think of a good reason why that silent blip is there...?

Now I'm going to have to go back and make sure the movies I've already processed hadn't been inflicted with this kind of crap.
ndjamena is offline  
Old 11th October 2015, 15:51   #13543  |  Link
buffyangel108
Scared of Iguanas
 
Join Date: Aug 2006
Posts: 32
Quote:
Originally Posted by tebasuna51 View Post
You can use the flac.exe encoder to put any parameter. For instance:

eac3to input stdout.wav | flac -o outfile.flac --ignore-chunk-sizes -0 -
Works a treat, thank you so much!
buffyangel108 is offline  
Old 11th October 2015, 16:22   #13544  |  Link
ndjamena
Registered User
 
Join Date: Sep 2012
Posts: 366
OK, conundrum:

Terminator Salvation, Extended Edition.

All the movie files are 24 bit DTS-MA with a real bitdepth of 16 bits, except for the very first one which is 16 bit with about 8000 bytes of 24 bit junk at the very beginning. All the "extended edition" m2ts file are actual 16 DTS-MA streams.

Since the first file is "pretend" 24 bit eac3to won't detect it as being 16 bit, but everything after that IS 16 bit. Since it doesn't realise what it's looking at is 16 bit, it's resampling all the 16 bit m2ts files to 24 bit so once the conversion is done there ARE 24 bit segments in there. But I have to extract the audio with either EAC3To or MakeMKV in order to remove the overlaps, but they BOTH resample the 16 bit to 24 bit which makes recovering the 16 bit almost impossible.

When I extract audio from an m2ts to WAV does EAC3To cut it so it's length matches the video stream?

Is there anything better I can do than extract MINUS the first file, process the first file separately and then append the two segments?
ndjamena is offline  
Old 11th October 2015, 16:28   #13545  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Extra 0 bits don't hurt the audio at all, so you could just leave it as is. Or since the only part that has 24-bit data is apparently "junk", just let eac3to process it in 24-bit and reduce to 16 afterwards if you want to save space.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline  
Old 11th October 2015, 16:34   #13546  |  Link
ndjamena
Registered User
 
Join Date: Sep 2012
Posts: 366
Doh!

The problem is that it's converting the 16 bit segments to 24 bit (at least if I process each m2ts file separately eac3to reports all but the first as being constant 16 bit, yet if I extract the whole movie with eac3to my program reports 24 bit segments in the resulting WAV file), it just occurred to me that maybe -dontdither will stop that. If I use -dontdither AND -down16 maybe...

Assuming it doesn't try to upsample the 16 bit first that should work. No?
ndjamena is offline  
Old 11th October 2015, 17:57   #13547  |  Link
ndjamena
Registered User
 
Join Date: Sep 2012
Posts: 366
Nope, -dontdither -down16 didn't work. Neither did -dontdither -down16 -dontPatchDts.

Leaving out the first file accomplishes nothing.

I'm out of options.

As far as I can tell there is no way of ripping mixed "16 bit in 24 bit" and "16 bit in 16 bit" tracks from a blu ray neatly as 16 bit using any program I can think of, much less with the addition of the junk in the first file.
ndjamena is offline  
Old 12th October 2015, 02:30   #13548  |  Link
Sparktank
47.952fps@71.928Hz
 
Sparktank's Avatar
 
Join Date: Mar 2011
Posts: 940
Then use just "-down16".
The final file for the whole stream will be 16bit.

If you want to keep it all, use FLAC. If you can't use FLAC, then take it with a grain of salt and convert all to 16-bit.
__________________
Win10 (x64) build 19041
NVIDIA GeForce GTX 1060 3GB (GP106) 3071MB/GDDR5 | (r435_95-4)
NTSC | DVD: R1 | BD: A
AMD Ryzen 5 2600 @3.4GHz (6c/12th, I'm on AVX2 now!)
Sparktank is offline  
Old 12th October 2015, 02:58   #13549  |  Link
ndjamena
Registered User
 
Join Date: Sep 2012
Posts: 366
If I use -down16 the STATED bit depth of the whole stream will be 16 bit, but the actual bit depth for the majority of the stream will be 10-bit...

Won't it?

(I have no idea what Eac3to is doing.)
ndjamena is offline  
Old 12th October 2015, 03:34   #13550  |  Link
Sparktank
47.952fps@71.928Hz
 
Sparktank's Avatar
 
Join Date: Mar 2011
Posts: 940
It... shouldn't.

It just means the whole stream will be dithered down to 16 bits, even the single, small, tiniest part that's actually 24-bit.
Anything that's actually 16bit will have nothing happen to it.

eac3to wouldn't dither below 16bit for anything.

The "stated" bit depth is 24 if you use the whole stream.
Using each segment (m2ts), the stated bit depth for each is what you observe: 16 or 24.
__________________
Win10 (x64) build 19041
NVIDIA GeForce GTX 1060 3GB (GP106) 3071MB/GDDR5 | (r435_95-4)
NTSC | DVD: R1 | BD: A
AMD Ryzen 5 2600 @3.4GHz (6c/12th, I'm on AVX2 now!)
Sparktank is offline  
Old 12th October 2015, 04:35   #13551  |  Link
ndjamena
Registered User
 
Join Date: Sep 2012
Posts: 366
Well, obviously I have no idea how audio works.

The wav files are little endian and as far as I can tell it is the most significant bits that are missing (the first byte of three).

The first byte of each group of 3 (24 bits) is zero, if the "endian" is "little" then that would make the first byte the "big" one... and that's what's missing...

Are the samples stored backwards for some reason?

Is it actually the LEAST significant bits that are missing?

That would solve everything.

-edit- oh, so either most significant doesn't mean biggest it means first, or "end" means "start"... or something...

From wikipedia:

For example, the number 123, has the hundreds-digit, 1, left-most which is understood by a numerate reader. This is an example of a big-endian convention taken from daily life.

-so little endian would store the byte that contains the smaller value first and downsampling would pretty much just remove that byte.

-edit2- Little Endian = LITTLE END FIRST

Last edited by ndjamena; 12th October 2015 at 05:02.
ndjamena is offline  
Old 12th October 2015, 08:25   #13552  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
The endianess makes no difference at all. Its just something for eac3to to handle, not for you to ever think about.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline  
Old 12th October 2015, 09:19   #13553  |  Link
ndjamena
Registered User
 
Join Date: Sep 2012
Posts: 366
I was looking at the WAV file with a hex editor to see what was going on.

Basically:

16 bit audio: 12
24 bit audio: 123
16 bit in 24 bit: 120
24 bit converted to 16 bit: 12
16 bit in 24 bit converted to 16 bit: 12


In case anyone else was confused as to how 16 bit in 24 bit audio was configured. The extra zeros are added to the small end of the sample, not the big end, effectively multiplying the value by 256. It's the equivalent of adding an extra zero to 12 to make 120 and alters the magnitude of the scale while keeping the same difference between the original sample points. 12 to 11 is the same as 120 to 110 but altering the zero gives you room to add precision which would give you the equivalent of true 24 bit audio.

That's why the volume stays the same between simply stripping the zeros and doing a proper resampling.

Stripping zeros is still better than resampling since resampling isn't lossless (with an even number of outcomes there's no middle point in whole byte numbers, it SHOULD be zero but then there will always be one more negative number than positive, so they simply don't scale well, silence (0s) winds up getting speckled with random noise(-1s)).

At least one person reading this thread didn't know that, and no one seemed willing to point it out.
ndjamena is offline  
Old 12th October 2015, 11:48   #13554  |  Link
tebasuna51
Moderator
 
tebasuna51's Avatar
 
Join Date: Feb 2005
Location: Spain
Posts: 6,890
@ndjamena
I read your discussion without understand what you want do.

1) Save space downsampling DTS-MA 24 to 16 bits in m2ts's?

a) If the main movie is a real 24 bits you lose precission, not volume.
b) If is real 16 bits and only credits have real 24 bits you can save only a few space.
c) If is a fake 24 bits (16 bits + 8 0's) you can save space without lose precission or volume.
d) If is 20 bits you lose less precission downsampling to 16 bits, but 20 bits is not a standard format and can't be used.

2) Save space when recode to a lossless format like FLAC?

Then in cases b) or c) is recommended, and safe, use -down16
In cases a) or c) you lose precission using -down16

3) About endianess.
You must trust in proper soft, like eac3to, than manage endianess without problems.
Only the less significant byte is deleted with -down16 and the volume remain the same.

When output .WAV and .W64 are always little endian samples.
And when output .PCM are always big endian samples. (not recommended use this format because is without header)
EDIT: Also when output multichannel .PCM the channel order is not the same than WAV or W64
__________________
BeHappy, AviSynth audio transcoder.

Last edited by tebasuna51; 12th October 2015 at 11:55. Reason: Add info
tebasuna51 is offline  
Old 12th October 2015, 12:19   #13555  |  Link
ndjamena
Registered User
 
Join Date: Sep 2012
Posts: 366
I ran out of hard drive space and discovered what a PITA trying to watch from the disc was, so I'm re-ripping, removing all the extra audio tracks and down sampling the main lossless tracks to 16 bit FLAC until I can afford a rack mount.

I saved 20GB just converting the audio to 16 bit FLAC on the X-Men movies alone so I figure I'm on the right track here.

(My WDTV SMP won't play 24 bit FLAC from an MKV without glitching, I had been converting to full bitdepth FLAC AND keeping the original track as well, plus all the commentary/audio description tracks and whatnot... so there's plenty of reasons to go down this track for now.)

I didn't know how 16 bits in 24 bits worked, from the simple way it's described I assumed it just used smaller numbers that would easily fit in a 16 bit integer, apparently Dark Space thought the same thing. But the numbers are the same size, it's just that the less significant 8 bits are empty, which is where the extra precision between 24 and 16 bit comes from, which leaves them pretty much exactly the same as 16 bit audio when those 8 bits are removed.

Should I have known that from the getgo?
ndjamena is offline  
Old 12th October 2015, 18:09   #13556  |  Link
ndjamena
Registered User
 
Join Date: Sep 2012
Posts: 366
When I used -down16 -dontdither on Terminator Salvation it destroyed the audio in the true 16 bit segments.

I'm thinking that's a bug, although I don't suppose I'm supposed to be using the -dontdither switch at all.

What would it have done? If it dithered the 16 bit up to 24 bit and then didn't dither it back to 16 bit it still should have turned out fine... no?

Would it have added zeros to the big end of the 16 bit section when up sampling and then taken the little end away when down sampling?

I should probably test it but I've deleted the blu ray structure and would have to rip it again.

-Edit- When using -down16 on silent PCM without -dontdither at least a sixth of the zeros are changed into either 1s or negative 1s.

Last edited by ndjamena; 12th October 2015 at 19:07.
ndjamena is offline  
Old 13th October 2015, 22:32   #13557  |  Link
gabbett1
Registered User
 
Join Date: Sep 2015
Posts: 67
Quote:
Originally Posted by Thunderbolt8 View Post
try this then: http://forum.doom9.org/newreply.php?...eply&p=1742199

remux the .m2ts file witj tsmuxer before trying to demux or anyhow process the atmos stream.
I'm confused. The link just puts me to reply to this forum.
gabbett1 is offline  
Old 13th October 2015, 23:07   #13558  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
^ I guess he caught a wrong URL in his clipboard; Ctrl+C is sometimes unreliable. It's probably this post (plus some previous and following). Apparently Transport Streams are not as trivial and unambiguous as one may expect.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline  
Old 14th October 2015, 16:41   #13559  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,197
yes, sorry. wrong ctrl+c
__________________
Laptop Lenovo Legion 5 17IMH05: i5-10300H, 16 GB Ram, NVIDIA GTX 1650 Ti (+ Intel UHD 630), Windows 10 x64, madVR (x64), MPC-HC (x64), LAV Filter (x64), XySubfilter (x64) (K-lite codec pack)
Thunderbolt8 is offline  
Old 20th October 2015, 13:25   #13560  |  Link
ndjamena
Registered User
 
Join Date: Sep 2012
Posts: 366
OK, so when appending an m2ts file with 16 bit DTS-MA to an m2ts file with 24 bit DTS-MA using eac3to even without using any switches, the 16 bit segment will be reduced to silence. All the higher order bits will be set to either FFF or 000 and the rest is pretty much nothing but noise. Extracting the 16 bit segment by itself produces perfect output. The fact that it doesn't issue an error or even a warning seems to indicate that that's actually a bug.

And when down sampling to 16 bit eac3to DOESN'T try to squeeze the number from a scale of 16777215 to a scale of 65535, it just removes the lower eight bits, then applies "dithering" which is basically just random noise to hide the artificial "colouring" of the sound any down sampling method must create. It applies the dithering even if what it's processing is nothing but perfect silence. The -dontdither switch supresses the application of any dithering.

Last edited by ndjamena; 20th October 2015 at 16:06.
ndjamena is offline  
Closed Thread

Tags
eac3to

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 03:31.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.