We are working with MOV files produced by Atomos Ninja V devices, which create a broken MOV file structure. The company is not responding to service such low level mistakes they made, but that is completely another topic.

**The issue:**
Audio is in "in24" format, as 24-bit 4-channel 48000 samples/second track (length 1.2sec in sample below). The path:

```
moov.trak[1].mdia.minf.stbl.stsz { 20-8 @ 65779208 = 12 }
    .       .    .    .    .     - version            = 00
    .       .    .    .    .     - flags[3]           = {00:00:00}
    .       .    .    .    .     - sample_size        = 00000003 = 3
    .       .    .    .    .     - number_of_entries  = 0000E100 = 57600
```

Given the 24-bit 4-channel configuration, one would expect a figure of 12 written in the constant sample size field. But they are made it wrong. Comparing it with other random internet found files, we see proper calculation of sample size, as a number that covers all bits of all channels = one audio sample in the time axis.

The consequence is dramatic - GPAC (and even my own mov reader code) would access only the first quarter of every given chunk, since we naturally use the sample_size * samples_in_chunk (of stsc). It does not return correct data when reading in our app using gpac library, and it does not return the correct -raw track dump using the MP4Box tool.

While we were debugging this odd behavior, I found that e.g. ffmpeg includes a quirk that overrides the constant sample_size with a calculated value that originates from the sample description (stsd) atom - if the audio is uncompressed, its easy to calculate the sample size. And this value is used then instead of the value that is read from the file - likely taking the path of - they got the data right, but they got some key metadata wrong.

**Potential solution**:
Could GPAC implement such override, eg. in the following way:
 - for simple lpcm/in24 format, decode the stsd and derive an expected sample_size
 - if the file indicated sample size is smaller, override it with the calculated size
 - emit a big warning, that the user deals with potentially broken file (ill formatted)
 - the functionality could be optional/masked, if there is a way to do it easily
 
**Alternative way:**
Is it possible to override the loaded isoMedia with a custom sample_size or stsz atom, when we are only using gf_isom_get_sample to read such file? We can easily detect this type of a badly setup MOV file.

quirk for a wrongly indicated audio sample size (format: in24)
This is a GitHub Issue
repo:gpac
owner:gpac
Title : quirk for a wrongly indicated audio sample size (format: in24)
Issue date:

--- start body ---
We are working with MOV files produced by Atomos Ninja V devices, which create a broken MOV file structure. The company is not responding to service such low level mistakes they made, but that is completely another topic.

**The issue:**
Audio is in "in24" format, as 24-bit 4-channel 48000 samples/second track (length 1.2sec in sample below). The path:

```
moov.trak[1].mdia.minf.stbl.stsz { 20-8 @ 65779208 = 12 }
    .       .    .    .    .     - version            = 00
    .       .    .    .    .     - flags[3]           = {00:00:00}
    .       .    .    .    .     - sample_size        = 00000003 = 3
    .       .    .    .    .     - number_of_entries  = 0000E100 = 57600
```

Given the 24-bit 4-channel configuration, one would expect a figure of 12 written in the constant sample size field. But they are made it wrong. Comparing it with other random internet found files, we see proper calculation of sample size, as a number that covers all bits of all channels = one audio sample in the time axis.

The consequence is dramatic - GPAC (and even my own mov reader code) would access only the first quarter of every given chunk, since we naturally use the sample_size * samples_in_chunk (of stsc). It does not return correct data when reading in our app using gpac library, and it does not return the correct -raw track dump using the MP4Box tool.

While we were debugging this odd behavior, I found that e.g. ffmpeg includes a quirk that overrides the constant sample_size with a calculated value that originates from the sample description (stsd) atom - if the audio is uncompressed, its easy to calculate the sample size. And this value is used then instead of the value that is read from the file - likely taking the path of - they got the data right, but they got some key metadata wrong.

**Potential solution**:
Could GPAC implement such override, eg. in the following way:
 - for simple lpcm/in24 format, decode the stsd and derive an expected sample_size
 - if the file indicated sample size is smaller, override it with the calculated size
 - emit a big warning, that the user deals with potentially broken file (ill formatted)
 - the functionality could be optional/masked, if there is a way to do it easily
 
**Alternative way:**
Is it possible to override the loaded isoMedia with a custom sample_size or stsz atom, when we are only using gf_isom_get_sample to read such file? We can easily detect this type of a badly setup MOV file.

--- end body ---
