Re: Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[batguano999]

>
> Many portable players have limited fast forward 
>and skipping capabilities so it makes it easier to skip to a file part way 
>through to resume listening.
>

Hi
I only split the files because my mp3 player won't play m4a files with duration 
greater than 30 minutes.
But yes, I agree, even if my player would play long m4a files it would probably 
be troublesome to seek and fast forward with a 2-hour or 3-hour file on this 
little player.

The re-muxed segmented files look like this...
0_Sounds_of_the_60s_-_Tim_Rice_sits_in_b08bqv5s_original.m4a
1_Sounds_of_the_60s_-_Tim_Rice_sits_in_b08bqv5s_original.m4a
2_Sounds_of_the_60s_-_Tim_Rice_sits_in_b08bqv5s_original.m4a
3_Sounds_of_the_60s_-_Tim_Rice_sits_in_b08bqv5s_original.m4a



___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[RS]

From: batguano999
Sent: Friday, January 27, 2017 09:38


So you could probably download a m4a radio show that is not longer than 
1800 seconds...

get_iplayer --force --mode=dashhigh --raw --type=radio url=
Then de-mux it...
ffmpeg -i foo.m4a -c copy foo.aac
Then re-mux it...
mp4creator -create=foo.aac NEW_foo.m4a


I do something like this all with the all de-mux/re-mux done in 
a --command.
get_iplayer --force --mode=dashhigh --raw --type=radio 
url= --command='WHATEVER'


Also with long shows I use a --command to split them into half hour 
segments and de-mux/re-mux them all.

The files play sequentially in my mp3 player.
After each half hour there is a "clunk" as the file changes.
Like an 8-track cart player back in the day.


That makes a lot of sense.  Many portable players have limited fast forward 
and skipping capabilities so it makes it easier to skip to a file part way 
through to resume listening.  My satellite receiver writes to an external 
USB drive which has to be formatted in FAT32.  To avoid going over the 
4GByte file limit it splits a recording into 500MByte files.  There is no 
clunk when it plays back its own recordings.




___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not

[Budge]

Hi Vangelis

On 26/01/17 23:46, Vangelis forthnet wrote:

On Thu Jan 26 18:45:27 GMT 2017, Budge wrote:


How do I add "hafbest" to my prefs.  Tried the obvious prefs-add
radiomode=hafbest but that gave me a search option!!!  Grateful for
some guidance please.


get_iplayer --radiomode=hafbest --prefs-add


I tried this and it didn't work so then went the long way thus:-

get_iplayer --prefs-add --radiomode hafhigh,hafstd,hafmed

Which is OK for me.
More important, using haf has solved my problem.  I have no idea why 
dash downloads started to go wrong.  Still researching.

Thanks for your message.
Best wishes,
Budge

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[batguano999]

>The resultant file with a duration of 1800s 
>(30min) did play on the AGPtEK player, but durations of 1900s and more did 
>not play. That is an improvement on 14min
>

So you could probably download a m4a radio show that is not longer than 1800 
seconds...
get_iplayer --force --mode=dashhigh --raw --type=radio url=
Then de-mux it...
ffmpeg -i foo.m4a -c copy foo.aac
Then re-mux it...
mp4creator -create=foo.aac NEW_foo.m4a

I do something like this all with the all de-mux/re-mux done in a --command.
get_iplayer --force --mode=dashhigh --raw --type=radio url= 
--command='WHATEVER'

Also with long shows I use a --command to split them into half hour segments 
and de-mux/re-mux them all.
The files play sequentially in my mp3 player.
After each half hour there is a "clunk" as the file changes.
Like an 8-track cart player back in the day.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[RS]

From: batguano999
Sent: Wednesday, January 25, 2017 15:50



The next question is how to convert AVC3 to AVC1 or AAC. I have already
tried using ffmpeg and its aac codec. It was very slow and I still 
couldn't

play the file. I have also tried the Nero encoder



This is pointless.
If you're converting from lossy to lossy aac you might as well convert from 
lossy to lossy mp3.


What I had in mind was something like
mp4box -bs-switching no
to force AVC1.  Also whether it is possible to force uniform sample rate to 
minimise the size of the staz table.



By the way, what about this?

Create a 30 minute "raw aac" test file with FFmpeg...
ffmpeg -f lavfi -i sine=d=1800 -y 1800_testfile.aac
Mux it into m4a with mp4creator...
mp4creator -create=1800_testfile.aac 1800_testfile.m4a
See if it plays OK... with your "£19 AGPtEK player"



From: iz
Sent: Wednesday, January 25, 2017 14:30


One other long shot to try is to remove the MP4 container by remuxing to 
plain old ADTS AAC. However, I'm guessing that even if that file played you 
>may not be able to seek/ff/rw, so of limited use. You could also feed the 
raw fragmented MP4 DASH file to your player, but I suspect that is even 
less >likely to be >supported.


I had already tried playing the raw file in VLC.  It played, but I noticed 
seeking was slow.  The file with the ADTS container did play in VLC, and 
seeking seemed normal.


With -f lavfi I got
Requested output format 'lavfi' is not a suitable output format
tfr1800.aac: Invalid argument

(I had renamed the raw file from .m4a to .aac but I got the same message 
when I renamed it back to .m4a)  I used -f adts instead.  The result was not 
playable in the AGPtEK player.


I did not understand the -i parameter so I used -t for the duration.

These were the commands
ffmpeg -i tfr.aac -f adts -t 1800 -acodec copy tfr1800.aac
mp4creator -create tfr1800.aac tfr1800.m4a

Without -acodec copy it converted from aac to aac using ffmpeg's built in 
codec, which was very slow.  The resultant file with a duration of 1800s 
(30min) did play on the AGPtEK player, but durations of 1900s and more did 
not play.  That is an improvement on 14min, but I noticed some drop outs not 
in the FLAC conversion.  I think I need to stick to FLAC or 320kbit/s MP3 
for music and 128kbit/s MP3 for speech.


I still have a lot to learn about the relationship between containers and 
content, and why a container can cause a problem for a player, or why AAC is 
so much more difficult to decode than MP3 or FLAC.  (The reason I commented 
on price was that AAC players generally seem to be a lot more expensive than 
MP3 players.)  I have been struck by how astonishingly little non-BBC AAC 
material is available for testing.  There is a lot of free MP3 material.  I 
do not use iTunes.


Thank you both for your suggestions and comments.






___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re "Issues with Large Files" and "Recent Radio Downloads Not

[Vangelis forthnet]

On Thu Jan 26 18:45:27 GMT 2017, Budge wrote:

How do I add "hafbest" to my prefs.  
Tried the obvious prefs-add radiomode=hafbest 
but that gave me a search option!!!  
Grateful for some guidance please.


get_iplayer --radiomode=hafbest --prefs-add

should do it...

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[Budge]

On 26/01/17 17:11, iz wrote:

Sent: Thursday, January 26, 2017 at 4:36 PM
From: Budge

profile"  error with this file.  I am using ffmpeg v3.2-6.5 but I do not
think it is an ffmpeg fault.  There was an update on my system on 17


ffmpeg 3.2 may be the culprit. That particular version caused a problem with remuxing 
DASH radio downloads that would lead to atomicparsley showing "unknown profile":

https://squarepenguin.co.uk/forums/thread-1095.html

If that is the case, you would need to remux with newer ffmpeg to another .m4a 
file.


Hi and thanks for the link.  Not sure about ffmpeg being the cause but 
read the thread and a few others.  I would like first to use haf instead 
of dash.  A one off trial just now seemed to work.


How do I add "hafbest" to my prefs.  Tried the obvious prefs-add 
radiomode=hafbest but that gave me a search option!!!  Grateful for some 
guidance please.

Budge

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[iz]

> Sent: Thursday, January 26, 2017 at 4:36 PM
> From: Budge
>
> profile"  error with this file.  I am using ffmpeg v3.2-6.5 but I do not 
> think it is an ffmpeg fault.  There was an update on my system on 17 

ffmpeg 3.2 may be the culprit. That particular version caused a problem with 
remuxing DASH radio downloads that would lead to atomicparsley showing "unknown 
profile":

https://squarepenguin.co.uk/forums/thread-1095.html

If that is the case, you would need to remux with newer ffmpeg to another .m4a 
file.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[Budge]

On 26/01/17 15:47, RS wrote:

From: Budge Sent: Thursday, January 26, 2017 11:01



I have not seen the Unknown profile message.



Try AtomicParsley  -T 1


I have not seen that message.  It may be that the files I have looked at
have been older than 17 Jan.  To make sure I had something up to date I
tried it with today's You and Yours (b0890kmf) from dashhigh1.
AtomicParsley said it was AAC Low Complexity.

Do you have an example of a programme pid which has the Unknown profile
error?  Are you using v3.0 of ffmpeg?


Hi and thanks for this.  I have just downloaded and I get the "unknown 
profile"  error with this file.  I am using ffmpeg v3.2-6.5 but I do not 
think it is an ffmpeg fault.  There was an update on my system on 17 
January and I think this is source of problem.  Will investigate elsewhere.

Thanks again,
Budge

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[RS]

From: Budge Sent: Thursday, January 26, 2017 11:01



I have not seen the Unknown profile message.



Try AtomicParsley  -T 1


I have not seen that message.  It may be that the files I have looked at 
have been older than 17 Jan.  To make sure I had something up to date I 
tried it with today's You and Yours (b0890kmf) from dashhigh1. 
AtomicParsley said it was AAC Low Complexity.


Do you have an example of a programme pid which has the Unknown profile 
error?  Are you using v3.0 of ffmpeg?








___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[Budge]

On 23/01/17 11:45, Budge wrote:
[snip]

... when I
chased Linn this is relevant part of the reply:-

"The issue is heavily influenced by but not directly related to track
duration. (Possibly too much technical detail - it's caused by the
number of entries in the 'stsz' table. Problem files have huge numbers
of entries, often with repeated small values; the mpeg spec allows but
doesn't encourage encoders to combine these blocks together.)"


The bottom line is that I was able to solve my large files problem by 
reverting to previous firmware on Linn Device.


Since there is nothing exceptional about these GiP radio download files 
I am very surprised that Linn, having issued a weak firmware update, are 
not jumping to put it right, but at least I was able to put things right 
for my purposes.  Many thanks to all who have contributed to my quest 
for a solution.


Finally for clarification I still have a problem with GiP radio 
downloads from 17 January 2017 but for a different reason.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[Budge]

On 25/01/17 00:21, RS wrote:

From: Budge Sent: Tuesday, January 24, 2017 10:38


I have not seen the Unknown profile message.


Try AtomicParsley  -T 1



___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[batguano999]

> 
>The next question is how to convert AVC3 to AVC1 or AAC. I have already 
>tried using ffmpeg and its aac codec. It was very slow and I still couldn't 
>play the file. I have also tried the Nero encoder
>
>
This is pointless.
If you're converting from lossy to lossy aac you might as well convert from 
lossy to lossy mp3.

By the way, what about this?
>Create a 30 minute "raw aac" test file with FFmpeg...
ffmpeg -f lavfi -i sine=d=1800 -y 1800_testfile.aac
>Mux it into m4a with mp4creator...
mp4creator -create=1800_testfile.aac 1800_testfile.m4a
>See if it plays OK... with your "£19 AGPtEK player"



___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[iz]

> Sent: Wednesday, January 25, 2017 at 11:46 AM
> From: RS
> 
> It seems that DASH is not simply AAC.  The adaptive bit rate may be what is 
> causing Linn to complain about the size of the stsz table.

"Adaptive bit rate" isn't an inherent property of a stream or the resulting 
file. That phrase just means that a player can choose among different bit rate 
streams in a single playlist based on characteristics of the playback 
environment. get_iplayer isn't an adaptive "player", so it's a moot issue in 
this case. Also, the raw DASH files for radio programmes don't use stsz and 
related tables. The files are fragmented MP4, so the sample information is 
spread over multiple track fragments. The st* tables are created during 
re-muxing, and only describe the audio content of the final file.

> The next question is how to convert AVC3  to AVC1  or AAC.  I have already 

AVC3 is only related to video, so has no bearing here. ffmpeg version 3 and 
above will do AVC3->AV1 during re-muxing, though.

> tried using ffmpeg and its aac codec.  It was very slow and I still couldn't 
> play the file.  I have also tried the Nero encoder, but my player did not 
> like the MP42 Major Brand or the .mp4 extension.

One other long shot to try is to remove the MP4 container by remuxing to plain 
old ADTS AAC. However, I'm guessing that even if that file played you may not 
be able to seek/ff/rw, so of limited use. You could also feed the raw 
fragmented MP4 DASH file to your player, but I suspect that is even less likely 
to be supported.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[RS]

From: Budge Sent: Tuesday, January 24, 2017 10:38


Have you looked at your files with AtomicParsley to see if you get the 
message I get "MPEG-4 Unknown profile" on your problem files?  It would be 
good to learn if we have the same problem.  This is no longer a long file 
problem.


Thanks for drawing attention to AtomicParsley.  I was aware of it because 
get_iplayer uses it, but I have never tried running it, and I didn't know 
how powerful it was.


Have you looked at the stsz tables to confirm what Linn said about them?

I have not seen the Unknown profile message.

I have not yet tried splitting a file into different length test files.  I 
have been using a file of over 2 hours.  I did create a DASHhigh download 
with the --raw option.  I was suprised that it created a file with a .m4a 
extension, because I thought that was a container.  Anyway mp4creator would 
not accept the .m4a extension for an input file.  I had to rename the file 
with a .aac extension.  I then got a large number of messages that a large 
number of bytes (about 400,000 each time) was being discarded.  I ended up 
with a file not even VLC could play about 1% of the original size.


I then tried to multiplex the raw file with ffmpeg.  I was surprised to see
major_brand: iso6
minor_version: 0
compatible_brands: iso6dash
When I tried to explore the raw file with AtomicParsely I got
AtomicParsley error: unsupported MPEG-4 file brand found 'iso6'

I am using the versions of ffmpeg (v3.0) and AtomicParsley (v0.9.6) bundled 
with v2.95 of get_iplayer and the Windows installer.


I have never seen ISO6 as a Major Brand before.  I gather it is a 2012 
revision of the MPEG4 standard.

https://en.wikipedia.org/wiki/ISO_base_media_file_format
It seems as recently as May 2013 VLC was unable to play ISO6 files.
https://sourceforge.net/p/gpac/discussion/287547/thread/5979f3d7/

Maybe the problem has something to do with that.








___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[Budge]

On 23/01/17 23:41, RS wrote:

From: batguano999
Sent: Monday, January 23, 2017 17:51



To check whether your version of FFmpeg creates m4a files that play
nice with the Linn...
Create some test files with different durations... 15 minutes, 30
minutes, 60 minutes etc. up to 3 hours.
If they all play OK then you can eliminate FFmpeg.


What does it mean if the shorter M4A/AAC  files play but longer ones
don't, because that is the situation I have?  I can get the files to
play if I run mp4box, which introduces 500ms interleaving, but only for
files up to about 14min.  Another symptom I have is that some of the
files sound as though they are being played at about 10 times the
intended speed.

Do you have any suggestions for multiplexers which work better with
problem players?


Hi, the symptom you describe files appearing to be played at speed has 
just surfaced on my phone app for one problem file so not all software 
is tolerant.


Have you looked at your files with AtomicParsley to see if you get the 
message I get "MPEG-4 Unknown profile" on your problem files?  It would 
be good to learn if we have the same problem.  This is no longer a long 
file problem.


What I do not understand is where and why this fault is present.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[batguano999]

> 
>What does it mean if the shorter M4A/AAC files play but longer ones don't, 
>because that is the situation I have? I can get the files to play if I run 
>mp4box, which introduces 500ms interleaving, but only for files up to about 
>14min.
> 
>Do you have any suggestions for multiplexers which work better with problem 
>players? 
>
Hi
Probably it means that your hardware player is very picky about how the aac is 
muxed.
Not as lenient as the software players such as VLC.

I am able to play m4a files up to 30 minutes duration when muxed with 
mp4creator program.

Create a 30 minute "raw aac" test file with FFmpeg...
ffmpeg -f lavfi -i sine=d=1800 -y 1800_testfile.aac

Mux it into m4a with mp4creator...
mp4creator -create=1800_testfile.aac 1800_testfile.m4a

See if it plays OK.

mp4creator is here ---> 
https://sourceforge.net/projects/mp4creator/files/mp4creator/version%201.6.1e-pre/

It works with Linux and Wine too...
~ $ wine ./mp4creator.exe -version
Z:\home\user\mp4creator.exe - mpeg4ip version 1.6.1e-pre





___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[RS]

From: batguano999
Sent: Monday, January 23, 2017 17:51


To check whether your version of FFmpeg creates m4a files that play nice 
with the Linn...
Create some test files with different durations... 15 minutes, 30 minutes, 
60 minutes etc. up to 3 hours.

If they all play OK then you can eliminate FFmpeg.


What does it mean if the shorter M4A/AAC  files play but longer ones don't, 
because that is the situation I have?  I can get the files to play if I run 
mp4box, which introduces 500ms interleaving, but only for files up to about 
14min.  Another symptom I have is that some of the files sound as though 
they are being played at about 10 times the intended speed.


Do you have any suggestions for multiplexers which work better with problem 
players?




___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[Budge]

On 23/01/17 19:21, batguano999 wrote:


To emulate the BBC files the command would be like this...
ffmpeg -f lavfi -i sine=d=900 -y -c:a aac -b:a 320k -ac 2 -ar 48000 
320k_900_FFmpeg.m4a


Thanks.  I have run 900 second and 3600 seconds.  Not a hint of any 
problem:-


AtomicParsley version: 0.9.6 (utf8)
--
Movie duration: 3600.022 seconds (01:0:0.02) - 226.56* kbp/sec bitrate 
(*=approximate)

Low-level details. Total tracks: 1
Trk  Type  HandlerKind  Lang  Bytes
1soun  SoundHandler   mp4a  und   101953952
 226.56 kbp/s  MPEG-4 AAC Low Complexity/LC Profilechannels: [2]

But I do not understand the 226.56 kbp/s.  What happened to the 320k?

Anyhow can we conclude that ffmpeg is not at fault?
In which case is the problem with BBC or GiP?
Has anybody else noticed this I wonder?
Is this a subject for bug report yet?
Grateful for guidance please.

Finally, please could you help with ffmpeg command I should put in prefs 
to go straight to FLAC rather than m4a.


Budge


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[batguano999]

> 
> 
>I would point out however that these files are mono at about 70 kbp/s 
>
To emulate the BBC files the command would be like this... 
ffmpeg -f lavfi -i sine=d=900 -y -c:a aac -b:a 320k -ac 2 -ar 48000 
320k_900_FFmpeg.m4a



___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[Budge]

On 23/01/17 17:51, batguano999 wrote:




Trouble is, if this is due to ffmpeg update, I have no idea when change
took place but certainly within the last week or so. (Or on reflection
was it when I upgraded from openSUSE 42.1 to 42.2??? Groan) How can I
find that info on my system? That would at least enable me to test and
if correct demonstrate to ffmpeg that they have introduced a bug.



Hi
To check whether your version of FFmpeg creates m4a files that play nice with 
the Linn...
Create some test files with different durations... 15 minutes, 30 minutes, 60 
minutes etc. up to 3 hours.
If they all play OK then you can eliminate FFmpeg.

This is how to ceate a 15 minute (900 second) test file.
ffmpeg -f lavfi -i sine=d=900 -y 900_FFmpeg.m4a
===


Hi and thanks for the suggestion.  I created 900 sec, 1800 sec and 3600 
sec and none showed any fault when checked with AtomicParsley. eg:-


AtomicParsley version: 0.9.6 (utf8)
--
Movie duration: 3600.024 seconds (01:0:0.02) - 69.29* kbp/sec bitrate 
(*=approximate)

Low-level details. Total tracks: 1
Trk  Type  HandlerKind  Lang  Bytes
1soun  SoundHandler   mp4a  und   31181746
 69.29 kbp/s  MPEG-4 AAC Low Complexity/LC Profilechannels: [1]


I would point out however that these files are mono at about 70 kbp/s 
whereas my problem files are at 320 kbp/s in stereo.  Would that make 
any difference?


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[batguano999]

> 
>Trouble is, if this is due to ffmpeg update, I have no idea when change 
>took place but certainly within the last week or so. (Or on reflection 
>was it when I upgraded from openSUSE 42.1 to 42.2??? Groan) How can I 
>find that info on my system? That would at least enable me to test and 
>if correct demonstrate to ffmpeg that they have introduced a bug. 
>

Hi
To check whether your version of FFmpeg creates m4a files that play nice with 
the Linn...
Create some test files with different durations... 15 minutes, 30 minutes, 60 
minutes etc. up to 3 hours.
If they all play OK then you can eliminate FFmpeg.

This is how to ceate a 15 minute (900 second) test file.
ffmpeg -f lavfi -i sine=d=900 -y 900_FFmpeg.m4a
===
===
@mint ~ $ ffmpeg -f lavfi -i sine=d=900 -y 900_FFmpeg.m4a
ffmpeg version git-2017-01-21-cde007d Copyright (c) 2000-2017 the FFmpeg 
developers
 built with gcc 5.4.0 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 20160609
 configuration: --enable-gpl --enable-libmp3lame --enable-libvorbis 
--enable-libx264
 libavutil 55. 43.100 / 55. 43.100
 libavcodec 57. 75.100 / 57. 75.100
 libavformat 57. 62.100 / 57. 62.100
 libavdevice 57. 2.100 / 57. 2.100
 libavfilter 6. 69.100 / 6. 69.100
 libswscale 4. 3.101 / 4. 3.101
 libswresample 2. 4.100 / 2. 4.100
 libpostproc 54. 2.100 / 54. 2.100
Input #0, lavfi, from 'sine=d=900':
 Duration: N/A, start: 0.00, bitrate: 705 kb/s
 Stream #0:0: Audio: pcm_s16le, 44100 Hz, mono, s16, 705 kb/s
Output #0, ipod, to '900_FFmpeg.m4a':
 Metadata:
 encoder : Lavf57.62.100
 Stream #0:0: Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 69 kb/s
 Metadata:
 encoder : Lavc57.75.100 aac
Stream mapping:
 Stream #0:0 -> #0:0 (pcm_s16le (native) -> aac (native))
Press [q] to stop, [?] for help
size= 7765kB time=00:15:00.00 bitrate= 70.7kbits/s speed=51.4x 
video:0kB audio:7613kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: 1.999211%
[aac @ 0x372b8e0] Qavg: 314.807
===
===
@mint ~ $ AtomicParsley 900_FFmpeg.m4a -T 1
...
--
AtomicParsley version: 0.9.6 (utf8)
--
Movie duration: 900.024 seconds (15:0.02) - 69.29* kbp/sec bitrate 
(*=approximate)
Low-level details. Total tracks: 1
Trk Type Handler Kind Lang Bytes
1 soun SoundHandler mp4a und 7795324
 69.29 kbp/s MPEG-4 AAC Low Complexity/LC Profile channels: [1]
===
===



___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[Budge]

On 23/01/17 17:24, RS wrote:

From: Budge



Sent: Monday, January 23, 2017 11:45



You will have to ask somebody who knows about these things but when I
chased Linn this is relevant part of the reply:-



"The issue is heavily influenced by but not directly related to track
duration. (Possibly too much technical detail - it's caused by the
number of entries in the 'stsz' table. Problem files have huge numbers
of entries, often with repeated small values; the mpeg spec allows but
doesn't encourage encoders to combine these blocks together.)"


This page describes stsz.
https://wiki.multimedia.cx/index.php/QuickTime_container#stsz
There are two modes, uniform sample size and different sample size.  I
assume the sample size is the number of bits to encode the level, namely
16. If there is a large table it must be because the different sample
size flag is set.  For a 9200s file the number of sample sizes would be
441,600,000. Unless the sampling frequency deviates from 48kHz, the
table size is directly related to track  duration.  I do not know why
the different sample size flag should be set; maybe it is the presence
of the thumbnail.  You could try running it through ffmpeg with -vn
-acodec copy.

Interestingly the Linn amplifiers support 24 bit encoding and a sampling
frequency of 192 kHz, which would make the stsz table 4 times as large.
(As the article you linked to said, 192kHz sampling is pointless or even
counter-productive, and there little to be gained by 24 bit encoding for
a production version.)

I did ask whether the number of samples per frame was always 1024.  It
seems it can also be 960 but 1024 is more common.

I thought you had given the name of the opera your Linn player would not
play, but going back through the thread all I could find was that it was
9200s, so it is fairly short.  Der Rosenkavalier is just under 5 hours.
I downloaded it from dashhigh1 and played it on my Triax satellite
receiver, which cost a tiny fraction of the cheapest Linn, and it played
all through. I skipped through it, but it played to the end without
problem, as have several shorter operas.



Again see my earlier posts.  I am convinced I am experiencing two 
different problems, corruption with profile which is occurring on short 
files and the long file Linn problem.  I did say they all play on my RPi 
without any problems.


The article to which I linked identified some technical benefits from 24 
bit during record production but explains clearly why not relevant at 
the listening end. Linn, however, from the days of vinyl lps, made and 
continue to make their money from the Golden Eared brigade who tend to 
believe that more must be better, whether bits or cash.  I have four 
Linn devices purchased because they worked reasonably reliably at a time 
when all similar kit used different proprietary standards but not as 
effectively or reliably. Unfortunately Linn is also all proprietary but 
the hardware works and is OK using apps like BubbleDS Next and 
BubbleUPnP for control points.  (Linn apps are inferior) I doubt, 
however, I shall buy any more Linn devices.




___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[RS]

From: Budge



Sent: Monday, January 23, 2017 11:45


You will have to ask somebody who knows about these things but when I 
chased Linn this is relevant part of the reply:-


"The issue is heavily influenced by but not directly related to track 
duration. (Possibly too much technical detail - it's caused by the number 
of entries in the 'stsz' table. Problem files have huge numbers of entries, 
often with repeated small values; the mpeg spec allows but doesn't 
encourage encoders to combine these blocks together.)"


This page describes stsz.
https://wiki.multimedia.cx/index.php/QuickTime_container#stsz
There are two modes, uniform sample size and different sample size.  I 
assume the sample size is the number of bits to encode the level, namely 16. 
If there is a large table it must be because the different sample size flag 
is set.  For a 9200s file the number of sample sizes would be 441,600,000. 
Unless the sampling frequency deviates from 48kHz, the table size is 
directly related to track  duration.  I do not know why the different sample 
size flag should be set; maybe it is the presence of the thumbnail.  You 
could try running it through ffmpeg with -vn -acodec copy.


Interestingly the Linn amplifiers support 24 bit encoding and a sampling 
frequency of 192 kHz, which would make the stsz table 4 times as large.  (As 
the article you linked to said, 192kHz sampling is pointless or even 
counter-productive, and there little to be gained by 24 bit encoding for a 
production version.)


I did ask whether the number of samples per frame was always 1024.  It seems 
it can also be 960 but 1024 is more common.


I thought you had given the name of the opera your Linn player would not 
play, but going back through the thread all I could find was that it was 
9200s, so it is fairly short.  Der Rosenkavalier is just under 5 hours.  I 
downloaded it from dashhigh1 and played it on my Triax satellite receiver, 
which cost a tiny fraction of the cheapest Linn, and it played all through. 
I skipped through it, but it played to the end without problem, as have 
several shorter operas.




___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[Budge]

On 23/01/17 15:36, batguano999 wrote:



Hi
I think that your problems are caused because the aac files muxed by FFmpeg 
into m4a when using get_iplayer are not compatible with your Linn DS devices.
This is also the case with some other hardware players. I know from personal 
experience.
Linn have told you "...the problems are caused by the file..."
And if you can be bothered to file a bug report to FFmpeg they will probably tell you 
that it is your player that's "buggy".
To play the BBC music files with their original aac data unconverted you might 
be able to do this by using a different m4a muxer instead of FFmpeg.
That's what I have to do.

But some work is needed, chatter about "radio 3 operas" and "The News Quiz" 
won't cut it.


Hi and many thanks for the info.  I have not been idle, I looked at the 
shorter files which will not play using AtomicParsley.  I suspected the 
file metadata.


No problems with the Atoms but there is a problem which I didn't see 
using mediainfo, probably through my ignorance.  I ran AtomicParsley 
 -T 1 and at the end of the files which do play I get:-


AtomicParsley version: 0.9.6 (utf8)
--
Movie duration: 1996.800 seconds (33:16.80) - 320.00* kbp/sec bitrate 
(*=approximate)

Low-level details. Total tracks: 1
Trk  Type  HandlerKind  Lang  Bytes
1soun  SoundHandler   mp4a  eng   79872007
 320.00 kbp/s  MPEG-4 AAC Low Complexity/LC Profilechannels: [2]


But at the end of those which do not, I get:-

AtomicParsley version: 0.9.6 (utf8)
--
Movie duration: 1670.400 seconds (27:50.40) - 320.00* kbp/sec bitrate 
(*=approximate)

Low-level details. Total tracks: 1
Trk  Type  HandlerKind  Lang  Bytes
1soun  SoundHandler   mp4a  eng   66816000
 320.00 kbp/s  MPEG-4 Unknown profile: 0x0channels: (2)

So the profile is not recognised by AtomicParsley.  Since I have not 
changed AtomicParsley in months the problem is either from BBC or ffmpeg.


Linn have raised an internal bug for the long file problem but it seems 
to me the above profile issue is another different problem.


Trouble is, if this is due to ffmpeg update, I have no idea when change 
took place but certainly within the last week or so.  (Or on reflection 
was it when I upgraded from openSUSE 42.1 to 42.2??? Groan)  How can I 
find that info on my system?  That would at least enable me to test and 
if correct demonstrate to ffmpeg that they have introduced a bug.


At the limit of my knowledge here but now have to write the correct 
ffmpeg command to encode the GiP into flac but without losing the 
tagging info which BBC are improving to a point where I can use it.
Grateful for some help with the command to add to my prefs if you have 
time please.

Budge

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[batguano999]

Hi
I think that your problems are caused because the aac files muxed by FFmpeg 
into m4a when using get_iplayer are not compatible with your Linn DS devices.
This is also the case with some other hardware players. I know from personal 
experience.
Linn have told you "...the problems are caused by the file..."
And if you can be bothered to file a bug report to FFmpeg they will probably 
tell you that it is your player that's "buggy".
To play the BBC music files with their original aac data unconverted you might 
be able to do this by using a different m4a muxer instead of FFmpeg.
That's what I have to do.

But some work is needed, chatter about "radio 3 operas" and "The News Quiz" 
won't cut it.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[Budge]

[snip]


What I haven't yet understood, both from the problem you have and the
problem I have, is why it is more difficult for a player to play a long
piece in AAC than in other formats.  I thought this was something
segmentation and fragmentation was supposed to deal with, to facilitate
streaming.


You will have to ask somebody who knows about these things but when I 
chased Linn this is relevant part of the reply:-


"The issue is heavily influenced by but not directly related to track 
duration. (Possibly too much technical detail - it's caused by the 
number of entries in the 'stsz' table. Problem files have huge numbers 
of entries, often with repeated small values; the mpeg spec allows but 
doesn't encourage encoders to combine these blocks together.)"


Hope this helps.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[michael norman]

Can't solve your problem, but if you have some Linn stuff you don't want 
I might make you an offer.  OT for this list I know.


M

On 01/18/2017 12:50 PM, RS wrote:

From: Budge



Sent: Sunday, January 15, 2017 13:11

The issue could be that Linn's player doesn't have enough memory to
read the sample tables from the file's MP4 container, so it refuses
to play the file. If >>so, splitting the file or transcoding to FLAC
are probably the best options.



Breaking up the download into acts would be a huge task and one I
cannot contemplate for more than a couple of favourites and with my
RPi working so well the Linn devices may be destined for ebay!


It seems a bit extreme to throw out the amplifier.  At 320kbit/s can you
tell the difference between AAC  and MP3 in a blind comparison?  You can
convert to MP3 after a download fairly effortlessly using a preset as
described here under Option Presets and Shortcuts and then Custom commands.
https://github.com/get-iplayer/get_iplayer/wiki/documentation
It takes about 6% of real time.  If MP3 is not acceptable, as suggested
you could convert to FLAC.

If the Linn player moves seamlessly from one file to the next you could
split it into fixed length files of half an hour or an hour.

What I haven't yet understood, both from the problem you have and the
problem I have, is why it is more difficult for a player to play a long
piece in AAC than in other formats.  I thought this was something
segmentation and fragmentation was supposed to deal with, to facilitate
streaming.



___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer



___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[Budge]

Thank you for the suggestion Richard, one of several I have received. 
Of course I could re code these files and I am sure I would not be able 
to hear any differences between file formats.  These types of argument 
have been well explained here 
https://people.xiph.org/~xiphmont/demo/neil-young.html


My problem is I have 450+ of these files and to do the job properly, 
breaking each work up into acts and scenes etc, naming and tagging the 
files would take months.   I would very much enjoy having the resulting 
library but do not have the time.


I am also very reluctant to use my time even transcoding in order to 
prop up a deficiency in a bunch of doubtful proprietary 
software/firmware which cost me several thousands of pounds rather than 
have the admitted deficiency to be rectified by Linn.  Meanwhile they 
play beautifully on my RPi.


I understand the issue is probably one of buffering and the buffer size 
written in the firmware.  Linn are aware of the issue but I have no idea 
when they will fix it.  It is possible your problem is similar.





On 18/01/17 12:50, RS wrote:

From: Budge



Sent: Sunday, January 15, 2017 13:11

The issue could be that Linn's player doesn't have enough memory to
read the sample tables from the file's MP4 container, so it refuses
to play the file. If >>so, splitting the file or transcoding to FLAC
are probably the best options.



Breaking up the download into acts would be a huge task and one I
cannot contemplate for more than a couple of favourites and with my
RPi working so well the Linn devices may be destined for ebay!


It seems a bit extreme to throw out the amplifier.  At 320kbit/s can you
tell the difference between AAC  and MP3 in a blind comparison?  You can
convert to MP3 after a download fairly effortlessly using a preset as
described here under Option Presets and Shortcuts and then Custom commands.
https://github.com/get-iplayer/get_iplayer/wiki/documentation
It takes about 6% of real time.  If MP3 is not acceptable, as suggested
you could convert to FLAC.

If the Linn player moves seamlessly from one file to the next you could
split it into fixed length files of half an hour or an hour.

What I haven't yet understood, both from the problem you have and the
problem I have, is why it is more difficult for a player to play a long
piece in AAC than in other formats.  I thought this was something
segmentation and fragmentation was supposed to deal with, to facilitate
streaming.



___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer



___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[RS]

From: Budge



Sent: Sunday, January 15, 2017 13:11
The issue could be that Linn's player doesn't have enough memory to read 
the sample tables from the file's MP4 container, so it refuses to play 
the file. If >>so, splitting the file or transcoding to FLAC are probably 
the best options.


Breaking up the download into acts would be a huge task and one I cannot 
contemplate for more than a couple of favourites and with my RPi working so 
well the Linn devices may be destined for ebay!


It seems a bit extreme to throw out the amplifier.  At 320kbit/s can you 
tell the difference between AAC  and MP3 in a blind comparison?  You can 
convert to MP3 after a download fairly effortlessly using a preset as 
described here under Option Presets and Shortcuts and then Custom commands.

https://github.com/get-iplayer/get_iplayer/wiki/documentation
It takes about 6% of real time.  If MP3 is not acceptable, as suggested you 
could convert to FLAC.


If the Linn player moves seamlessly from one file to the next you could 
split it into fixed length files of half an hour or an hour.


What I haven't yet understood, both from the problem you have and the 
problem I have, is why it is more difficult for a player to play a long 
piece in AAC than in other formats.  I thought this was something 
segmentation and fragmentation was supposed to deal with, to facilitate 
streaming.




___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[Budge]

Hi Richard,

On 14/01/17 15:20, iz wrote:

Sent: Saturday, January 14, 2017 at 12:05 PM
From: RS

always suspicious of people who refer to "chunks" when there is a recognised


I suspect they are using "chunk" from MP4 parlance, though a chunk contains multiple 
audio blocks ("samples" in MP4).


Does the Linn play all the files in a directory in turn?  It it does, would
it help to split the file into separate files for each act of the opera?


The issue could be that Linn's player doesn't have enough memory to read the 
sample tables from the file's MP4 container, so it refuses to play the file. If 
so, splitting the file or transcoding to FLAC are probably the best options.


Thanks for the replies and yes I take the point about the arithmetic.
I too am surprised by Linn's response and the memory shortage seems most 
plausible.  What I do not understand is why they have not come across 
this before.  I shall pursue them on this and report back.


Breaking up the download into acts would be a huge task and one I cannot 
contemplate for more than a couple of favourites and with my RPi working 
so well the Linn devices may be destined for ebay!





___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[iz]

> Sent: Saturday, January 14, 2017 at 12:05 PM
> From: RS
> 
> always suspicious of people who refer to "chunks" when there is a recognised 

I suspect they are using "chunk" from MP4 parlance, though a chunk contains 
multiple audio blocks ("samples" in MP4).

> Does the Linn play all the files in a directory in turn?  It it does, would 
> it help to split the file into separate files for each act of the opera?

The issue could be that Linn's player doesn't have enough memory to read the 
sample tables from the file's MP4 container, so it refuses to play the file. If 
so, splitting the file or transcoding to FLAC are probably the best options.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[RS]

From: iz



Sent: Friday, January 13, 2017 20:19


In this case, you only need arithmetic. AAC uses a fixed number of samples 
per frame (the "1024 spf" you see in the frame rate in MediaInfo output), 
so the >total number of frames is basically a function of sample rate and 
programme duration. 400k+ would be expected for a 48kHz 9200 sec AAC LC 
file.


If that's the case there is no point in making the suggestion I was about to 
make, but I'll make it anyway.


The problem I had with AGPtEK was that they had done their testing with 
files about 7 years old, so they could not take account of recent changes 
such as the M4A Minor Version 512, and clips of only 3 or 4min.  If Linn's 
problem had been similar I was going to suggest re-encoding with the Nero 
AAC encoder, which I understand is highly regarded, but is of a similar age. 
It means using the decoder to convert from .M4A/.AAC to .WAV and then 
re-encoding with the encoder.  That is not as daunting as it sounds.  The 
decoder is very fast.  The encoder is much faster than the AAC codec built 
in to ffmpeg.  It encodes a 24min 128kbit/s file in 20s, which compares with 
about 10min for the ffmpeg aac codec.


It is no longer available on nero.com, but it is here
http://www.softpedia.com/get/Multimedia/Audio/Audio-CD-Rippers-Encoders/Nero-Digital-Audio.shtml

I have looked at some files ranging from 12kbit/s with an 8kHz sample rate 
to 320kbit/s with a 48kHz sample rate.  They all have 1024 samples per 
frame.  Is that part of the AAC standard?  If it is, it is inevitable that 
with a sampling rate of 48kHz there are going to be just under 47 frames per 
second.  What is surprising that Linn were surprised by it, although I am 
always suspicious of people who refer to "chunks" when there is a recognised 
technical term.


Does the Linn play all the files in a directory in turn?  It it does, would 
it help to split the file into separate files for each act of the opera?




___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[iz]

> Sent: Thursday, January 12, 2017 at 3:30 PM
> 
> My question is with what does one look at a file to find out this info. 
> I tried mediainfo and am none the wiser.  What tool gives me the detail 
> to which Linn referred?

In this case, you only need arithmetic. AAC uses a fixed number of samples per 
frame (the "1024 spf" you see in the frame rate in MediaInfo output), so the 
total number of frames is basically a function of sample rate and programme 
duration. 400k+ would be expected for a 48kHz 9200 sec AAC LC file.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[Budge]

On 13/01/17 00:24, RS wrote:

From: Budge Sent: Thursday, January 12, 2017 18:26



Many thanks.  Yes I agree ffmpeg was my first thought but I am spoiled
for choice of command options.  ffprobe output didn't tell me what I
was looking for although that may be due to me not understanding what
I was looking at.  However I have no doubt ffmpeg will clean things
up.  I shall try a few options and see what happens.


Thanks for drawing attention to this.  I did hope something similar
might lead to a solution of the problem I have playing DASH/M4A/AAC
files on my AGPtEK A02.  I found about a year ago that ffmpeg created
files with Major Brand M4A and Minor Version 512, which the AGPtEK
player  did not seem to like.  I used
mp4box  .m4a -brand M4A:0 -out .m4a
from https://gpac.wp.mines-telecom.fr/mp4box/mp4box-documentation/
to change the Minor Version to 0.  I then found I could play the files,
but only if they were shorter than 14min at 128kbit/s.

Following your post I have looked at it again.  I see that by default
mp4box -brand M4A introduces interleaving of 500ms.  I tried
mp4box  .m4a -brand M4A:0 -inter 1000 -out .m4a
to give 1s interleaving and that allowed a 24min file to be played, but
the display showed Format error after 15min.  I also tried -inter 2000
for 2s interleaving.  That again allowed a 24min file to be played but
with a Format error after 5min.

mp4box  -info
gives a bit more information than ffprobe and ffmpeg.  GPAC refers to
segments, fragments and interleaving.  I am not sure how these relate to
what Linn calls chunks.

I have tried running ffmpeg with -acodec copy and with -acodec aac, but
that does not seem to help.

artisticforge said Handbrake fixed his files.  Handbrake will not
convert audio only files.  I have seen a workaraound to add dummy video,
but that seemed a bit cumbersome.  I'll have to give it a try.



Interesting.  I thought I would have a look at mp4box but cannot find it 
although I have gpac installed.  I could download and build but wonder 
why it is not shown in Packman repo along with gpac.  Will dig further.


Meanwhile I am learning (slowly) a whole lot more about this through 
necessity.  I should point out however that my files are from 2 hours 
and up to more than twice as long.  Strange that only the Linn kit 
chokes on these but they are now aware of the issue.




___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[RS]

From: Budge Sent: Thursday, January 12, 2017 18:26


Many thanks.  Yes I agree ffmpeg was my first thought but I am spoiled for 
choice of command options.  ffprobe output didn't tell me what I was 
looking for although that may be due to me not understanding what I was 
looking at.  However I have no doubt ffmpeg will clean things up.  I shall 
try a few options and see what happens.


Thanks for drawing attention to this.  I did hope something similar might 
lead to a solution of the problem I have playing DASH/M4A/AAC files on my 
AGPtEK A02.  I found about a year ago that ffmpeg created files with Major 
Brand M4A and Minor Version 512, which the AGPtEK player  did not seem to 
like.  I used

mp4box  .m4a -brand M4A:0 -out .m4a
from https://gpac.wp.mines-telecom.fr/mp4box/mp4box-documentation/
to change the Minor Version to 0.  I then found I could play the files, but 
only if they were shorter than 14min at 128kbit/s.


Following your post I have looked at it again.  I see that by default 
mp4box -brand M4A introduces interleaving of 500ms.  I tried

mp4box  .m4a -brand M4A:0 -inter 1000 -out .m4a
to give 1s interleaving and that allowed a 24min file to be played, but the 
display showed Format error after 15min.  I also tried -inter 2000 for 2s 
interleaving.  That again allowed a 24min file to be played but with a 
Format error after 5min.


mp4box  -info
gives a bit more information than ffprobe and ffmpeg.  GPAC refers to 
segments, fragments and interleaving.  I am not sure how these relate to 
what Linn calls chunks.


I have tried running ffmpeg with -acodec copy and with -acodec aac, but that 
does not seem to help.


artisticforge said Handbrake fixed his files.  Handbrake will not convert 
audio only files.  I have seen a workaraound to add dummy video, but that 
seemed a bit cumbersome.  I'll have to give it a try.






___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[Budge]

On 12/01/17 16:14, Jim web wrote:

In article <37968d10-ab7a-f131-e07d-00b58cc2a...@errichel.co.uk>, Budge
 wrote:

On 10/01/17 22:48, Budge wrote: [snip] Linn advised thus.



As a workaround for now, you could convert the file to a different
format. I've checked that it plays after converting to either FLAC
or ALAC using dbpoweramp.

You might even find that just re-writing it as AAC fixes things -
the problems are caused by the file being split into an enormous
number of tiny chunks (over 400,000 audio blocks for a 9,200 second
track); any encoder which reduced this would allow the file to play.



My question is with what does one look at a file to find out this info.
I tried mediainfo and am none the wiser.  What tool gives me the detail
to which Linn referred?


I can't give a specific answer. But my own reaction whenever I want to try
and examine AV files or process them is to turn to the ffmpeg family. (In
practice, they are also what is 'under the GUI' of many other programs for
AV.) I suspect ffmpeg will 'clean' the file for you. The ffprobe program
may well tell you more about it.



Hi Jim,
Many thanks.  Yes I agree ffmpeg was my first thought but I am spoiled 
for choice of command options.  ffprobe output didn't tell me what I was 
looking for although that may be due to me not understanding what I was 
looking at.  However I have no doubt ffmpeg will clean things up.  I 
shall try a few options and see what happens.

Regards,
Budge


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[Jim web]

In article <37968d10-ab7a-f131-e07d-00b58cc2a...@errichel.co.uk>, Budge
 wrote:
> On 10/01/17 22:48, Budge wrote: [snip] Linn advised thus.

> >>> As a workaround for now, you could convert the file to a different
> >>> format. I've checked that it plays after converting to either FLAC
> >>> or ALAC using dbpoweramp.
> >>>
> >>> You might even find that just re-writing it as AAC fixes things -
> >>> the problems are caused by the file being split into an enormous
> >>> number of tiny chunks (over 400,000 audio blocks for a 9,200 second
> >>> track); any encoder which reduced this would allow the file to play.

> My question is with what does one look at a file to find out this info.
> I tried mediainfo and am none the wiser.  What tool gives me the detail
> to which Linn referred?

I can't give a specific answer. But my own reaction whenever I want to try
and examine AV files or process them is to turn to the ffmpeg family. (In
practice, they are also what is 'under the GUI' of many other programs for
AV.) I suspect ffmpeg will 'clean' the file for you. The ffprobe program
may well tell you more about it.

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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[Budge]

On 10/01/17 22:48, Budge wrote:
[snip]
Linn advised thus.


As a workaround for now, you could convert the file to a different
format.
I've checked that it plays after converting to either FLAC or ALAC using
dbpoweramp.

You might even find that just re-writing it as AAC fixes things - the
problems are caused by the file being split into an enormous number
of tiny
chunks (over 400,000 audio blocks for a 9,200 second track); any encoder
which reduced this would allow the file to play.


My question is with what does one look at a file to find out this info. 
I tried mediainfo and am none the wiser.  What tool gives me the detail 
to which Linn referred?



___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[Budge]

Hi and many thanks for the info.  I shall play around with Handbrake and 
ffmpeg and see which gives the best result.


I find it significant that this is only a problem with larger files.  I 
wonder what the size threshold is and why.


Will report back.  Also need to see how to automate the cleaning up 
process on the back of GiP.


Regards,
Budge

On 10/01/17 14:24, artisticforge . wrote:

hello

I have noticed this also. iTunes would not import audio & video files
into the iTunes Library.
While researching the cause it became apparent that the files were
thousands of small chunks.
I have found that running them through Handbrake "fixes" them.

i do not see anything that get_iplayer may do to alleviate  the
problem. this is a BBC issue.


On Tue, Jan 10, 2017 at 4:23 AM, Budge  wrote:

I have recently had trouble playing radio 3 operas on my Linn devices. These
files used to play although there were problems.  They play well on my RPi3
with IQaudIO DAC+ amd upmpdcli gapless player software. (Totally brilliant
setup which enables me to use excellent power amplifiers which would
otherwise be redundant.)

I asked Linn for help which they are working on and received this reply:-

As a workaround for now, you could convert the file to a different format.
I've checked that it plays after converting to either FLAC or ALAC using
dbpoweramp.

You might even find that just re-writing it as AAC fixes things - the
problems are caused by the file being split into an enormous number of tiny
chunks (over 400,000 audio blocks for a 9,200 second track); any encoder
which reduced this would allow the file to play.

Please could somebody tell me if this is correct and what should be there or
have I done something wrong with my gip installation.
Budge

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer






___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[Stuart Jarvis]

On 2017-01-10 14:24, artisticforge . wrote:

While researching the cause it became apparent that the files were
thousands of small chunks.
I have found that running them through Handbrake "fixes" them.

i do not see anything that get_iplayer may do to alleviate  the
problem. this is a BBC issue.


Maybe related to DASH/HLS etc? (Aren't these now the defaults and us I 
understand it use lots of tiny chunks to enable bit rate switching on 
the fly if needed?) Perhaps forcing a non-DASH/HLS mode - one of the old 
'flash' modes perhaps, if still available - could be a workaround?


Pure guesswork, might be totally wrong...

Stu

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[artisticforge .]

hello

I have noticed this also. iTunes would not import audio & video files
into the iTunes Library.
While researching the cause it became apparent that the files were
thousands of small chunks.
I have found that running them through Handbrake "fixes" them.

i do not see anything that get_iplayer may do to alleviate  the
problem. this is a BBC issue.


On Tue, Jan 10, 2017 at 4:23 AM, Budge  wrote:
> I have recently had trouble playing radio 3 operas on my Linn devices. These
> files used to play although there were problems.  They play well on my RPi3
> with IQaudIO DAC+ amd upmpdcli gapless player software. (Totally brilliant
> setup which enables me to use excellent power amplifiers which would
> otherwise be redundant.)
>
> I asked Linn for help which they are working on and received this reply:-
>
> As a workaround for now, you could convert the file to a different format.
> I've checked that it plays after converting to either FLAC or ALAC using
> dbpoweramp.
>
> You might even find that just re-writing it as AAC fixes things - the
> problems are caused by the file being split into an enormous number of tiny
> chunks (over 400,000 audio blocks for a 9,200 second track); any encoder
> which reduced this would allow the file to play.
>
> Please could somebody tell me if this is correct and what should be there or
> have I done something wrong with my gip installation.
> Budge
>
> ___
> get_iplayer mailing list
> get_iplayer@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/get_iplayer



-- 
terry l. ridder ><>

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Issues with Large Files

[Budge]

I have recently had trouble playing radio 3 operas on my Linn devices. 
These files used to play although there were problems.  They play well 
on my RPi3 with IQaudIO DAC+ amd upmpdcli gapless player software. 
(Totally brilliant setup which enables me to use excellent power 
amplifiers which would otherwise be redundant.)


I asked Linn for help which they are working on and received this reply:-

As a workaround for now, you could convert the file to a different 
format. I've checked that it plays after converting to either FLAC or 
ALAC using dbpoweramp.


You might even find that just re-writing it as AAC fixes things - the 
problems are caused by the file being split into an enormous number of 
tiny chunks (over 400,000 audio blocks for a 9,200 second track); any 
encoder which reduced this would allow the file to play.


Please could somebody tell me if this is correct and what should be 
there or have I done something wrong with my gip installation.

Budge

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer