Refresher Requested on MPEG4 Container and AtomicParsley

[Kevin Lynch]

Budgie

>From reading through this thread and it's explanation of the legacy
mp3 creation process. I think it's clear the best approach is to put
these files through something like winff and regenerate the mp3.
To better understand the scope of what's involved. How many files do
you have? How much disk space do they currently use?
If you can upload an example of the media to a network file sharing
service (google drive/drop box) on a private link (smallest file
example that exhibits the issue) and share the access url with the
group. We can see which winff/ffmpeg parameters do the quickest
regeneration while maintaining the essence.
I had a look at  https://ffmpeg.org/ffmpeg.html#Detailed-description
and it shows the process you will want to use for "fixing the mp3"
files.
Although https://ffmpeg.org/ffmpeg.html#Stream-copy is used to change
the container eg mkv->mp4 and I don't think that process will generate
the index marks needed for the mp3 to be able to scrub around
Kevin





On 29 July 2015 at 09:30, Jim web <web at audiomisc.co.uk> wrote:
> 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
>
>
> _______________________________________________
> get_iplayer mailing list
> get_iplayer at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/get_iplayer