Refresher Requested on MPEG4 Container and AtomicParsley

[Jim web]

In article <55B7C97F.3010701 at errichel.co.uk>, Budgie
<ajebay at errichel.co.uk> wrote:
> Been reading all afternoon to trying and understand source of one of my
> problems when seeking within Radio 3 downloads, which for my Linn DS
> renderers I am advised by Linn is as follows:-

[snip]

> Opening the file in a hex editor and locating the stco box reveals that
> there is only one chunk offset, which points to the start of the audio
> data within the file.

I'm not sure someone using a hex editor would be the best way to establish
that. They could easily find some details and miss others. However they
don't seem to mention that the file should be fixed-rate, which should make
life easier for a renderer, or a for a 'fix' program. (Assuming the payload
itself isn't garbled, which may occur. I've seen that once or twice here, I
think. But this should be rare.)

> So, with such a file, the DS is only able to seek to the start of the
> track."

> This fits the synptoms and I assume is correct so I want to understand
> why some downloads apparently do have multiple chunk offsets and others
> only one.

What Vangelis has written in reply should be a good basis for what you can
try.

My experience - with DVB-T2 streams - is that the behaviour of various
versions of ffmpeg/avconc did vary. These streams aren't quite the same as
a downloaded file because they are grabbed sections of a stream, whereas
gip essentially fetches a pre-defined file. But...

In general, using a method like the one Vangelis exampled should 'clean'
the result and insert any needed timestamp info that may have gone awol.

However I found that in some cases this didn't work properly. So I could
get some cases where the result played from the start, and the elapsed time
and duration shown by VLC seemed fine. But any attempt to 'jump' to a
different time caused the values to be wrong, or zero, and playback might
crash.

In some cases 'cleaning' of these seems impossible, but I suspect these
were grabbed with too low a UHF signal/noise ratio so have flaws in the
data stream that ffmpeg, etc, can't understand or fix. That said the
DVB-T/T2 standards *use* seemed a bit of a wild west a few years ago. 8-]

So it is possible that either the files you fetched were sufficiently
'broken' and/or the version of ffmpeg/avcon you were using simply didn't
sort this out immediately after fetching. Another pass though a newer
ffmpeg might fix it, though.

If not, as audio, you can finally bail out and convert to lpcm wav.The
standard wave format just has a header followed by the lpcm sample values.
If that sounds OK, it can be re-encoded if you wish to save space. Although
I would recommend a loss-free method like flac to avoid needless reduction
in quality if you get to this stage.

Jim

-- 
Electronics  http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio  http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc  http://www.audiomisc.co.uk/index.html