View Single Post
Old 3rd February 2016, 22:36   #29
vasdrakken
Junior Member
 
Join Date: Feb 2016
Posts: 1
This might help.

AVI is the container, it has a encoder file stored in the header. The hex code will be either hashed with the stored encoder making it a MP4, MKV, M4P, M4A, AAC, NERO AAC, etc...

There are four parts.
+ One the header file. This is usually documented in a standard dot h file before being complied or encoded. This lists the number of tracks how much data is supposed to be in both and the stops and headers of the tracks below. Ie it means that if it was recorded as analog at 44.1 Hertz basically fourty four thousand sample per second verse forty eight thousand samples per eight of a second. the sampling of 48 has more lead in than 44 because even though is samples every 48 thousandth of a second it does this eight times. Those are then over laid over each other and the best avg is kept. To get a MKV or MP4 instead of AVI you toss the rest of the codecs and only leave the codec info for that encoding. So they are still AVI containers but they save space by not have to store the encoding data for all the formats they did not encode with. Which is why AVI will play on more systems if the codecs are missing because they can use the frame of reference for all the other codec's stored in that AVI container header. So if you are looking at AAC files they can have more than one codec stored in the header like nero would store H.264, H263, H261, and a bunch of variations of VC1, H.264 Part 10. So that older stuff would still be readable by their decoder. But it is still the AVI container file and has to follow the binary and plain text encoding rules. So did up those or read through the Matroska Vision format of the AVI container, it will help explain how the AVI container works. All of these are AVI: AVI, ASF, MOV, RM, MP4, MPG ES, but to protect their work claim they are new and improved containers but can be renamed and run through direct show to decode the avi data. Advance Vector Indices.
+ Two the video track data, I was told years ago when I was working on encoding that the audio tracks follow because the screen has to have something on it even if just a black box. The joke being that black boxes in object oriented coding are functions that the person maintaining the code does not need to understand as long as they take the expected info and return the expected results. The other joke was that light travels faster than sound so it went first. the last rumor I heard was that once the video is compressed if stuff needs to be lost it is better to have video meet a minimum threshold as the sound can be compressed into rougher digital vector data while still sounding the same if it is played and recorded at fast enough hertz. The video data is stored as frames or series of pictures. There is no actual way to store motion data unless you store it like 3D dimensional audio data then you get mocap data and no pictures, just point cloud data. Basically think about like this the images are a number of tracks specified in the header of pictures that the header tells the codec how often to change the picture how the bits can be compressed. Like with jpg the picture uses something like raid data it multiples the images against grey and when it can reproduce within a percentage of the same math that is what is save. Lazco is really cool. Then to get a zip file those are then treated as numbers and stored so that the numbers can be reproduced with no errors. Lossy verse lossless. The first is lossy jpg and the second zip is lossless. Since the first can have errors as long as you can not see them and the second is not allowed any errors.
+ The audio tracks.
AVI is the designed to store bits like a wave file does pre-encoded analog vector data. Think of it as a series of spline curves stored at wave height table and trough distance vector. IE a direction and speed. So the un compressed data is a series of arrows pointing left and from zero pointing directly down to mean a highlight sound or an eight note. If you look at how old school midi files are built you can see this.
Basically think of it as series of arrows with a number behind them. They all point to the right of the screen unless less than three and greater than one seventy five or so. When they point like they are eight notes holding the previous sound or raising or falling note. The notes falling or getting deeper in the trough the notes raising are rasing in pitch the thing is notes stored by the highest point that is set when they are encoded by bit depth. so when you are recording and the notes start getting deeper or higher the bars start scaling the previous recorded notes smaller. The vectors when you hit stop lock the recording to sample based on the highest or lowest note. It is always stored and equal distance from flat which is ninety. Ninety sounds like Alvin and the chipmunks... or really bad speed metal. lol. There is some that impressive for the sheer skill but still sounds like they are wasting their time playing... but there are some that impressive because they are hitting the notes long enough to be heard then the next without skipping any. Those are usually seventy or lower and one hundred and ten or higher.

>>>///>>\\\ etc...
+ The last part is the extra stuff... like file security and copyright data stuff you see in grace note and on the file itself.

MPG or MP1 did not have this it was built when the MP3 file format was created and was just the header and muxed data files. IE it was encoded it tracks or streams.The compressed as one encrypted file. Apples first version of M4A was like this with the last part stored in a separate file and when they brought it over to the PC side of things they had to make a file with all of encrypted streams as one file like a MP1 file. Which meant the only thing that could decrypt it was the apple software as the public hash or public key was in the software and the private key was encoded into the file when you bought it which is why they did not let people re download everything because their servers took a hit when some one bought a lot of music and if someone needed those new keys generated until the machines got fast enough that generating a hash was no big deal. That and people had to use the right version some times to get their music to work if the key structure changed too much.

Hopefully this helps.
Benjamin Solheim.
I had another account on here at some point I used winamp to play my protected files from apples store on my android phone. grin.
vasdrakken is offline   Reply With Quote