Working with large and long audio files

[hdradio]

A friend (radio station owner) asked me if PFOA can work with very large audio files.
He records live concerts and wants to rebroadcast them. The files are in wav and their size are greater than 500MB each.
I didn't know the answer and I tried a test on a spare (old P4 1,5GB ram) pc.
I found an mp3 file (a 15 hours day recording) sized about 1GB. This file is on my networked OnAir pc.
I open it with xmplay (bass) and opens instantly. I can move forward and backward instantly too.
I run PFOA. While PF is idle CPU label shows about 10% load. I don't know what background tasks are performed but it's ok.
I then Click New Playlist. I drag the file from windows explorer to the empty pf playlist.
CPU now is 19%. I suppose it tries to load the file in background.
I click F9. It does not start playback.
01min & 50secs later the wave panel shows the name of the file instead of the waveform. I guess it's ok because this is a large file and can not render the whole file.
But it took 01min and 50secs for this. Now the CPU load is 60%.
I wait a few minutes. Still cpu is 60%.
I click F9. File now starts to play. If I click on the upper half of the wave window (where is now the name of the file) it does not move playback forward. Instead if I move the bar below I can move the playback to the desired position.
I click "Play/Stop". The file stops playing and is removed from playlist. Ok.
But the CPU load stays at 60%.
I close (the empty) playlist. Still 60%
I wait a few minutes. Still 60%.
Finally I close PFOA.
Can you check it please? I think that a background task is not stopped as it should.

Edit: I rechecked and after closing the file the cpu dropped to 10% 20 minutes later.
During that time in task manager I see about 13Mbps ethernet receive.

[hdradio]

The mp3 I tried is 128 kbps sample rate 44100
I loaded it into DJ player.
I mentioned xmplay because it uses the same library as PF. I know that xmplay does not do any background processing when idle. That's why I noted that PF's cpu load is ok when idle.

I tested again using the following settings:

WaveForm limit: 1800sec

BPM Detection:
Enable Beat detection : Unchecked
Live BPM Calculation : Checked
Auto BPM Calculation : Unchecked

Replay Gain:
Mode: Off
Use ReplayGain in ACPD : Unchecked
AutoReplayGain calculation: Unchecked

File was able to play after 1,50min after dropping into playlist.
When double click on it to PFL, title was "loading" for the same time.

[radio42]

That is then indeed strange; I just created a 1 GB MP3 file (17 hours in length) myself (also using 44.1Khz, 128kpbs)...and that played almost immediately here (it took something like 1 sec. to load and play)...also seeking was working perfectly fine...

So the only other difference between PF and xmplay is, that PF uses the 'PRESCAN' as well as the 'ASYNC' flag when opening a file.
The 'PRESCAN' option reliably determines the absolute exact file length (duration), which is needed in PF and not needed in xmplay (if not used the duration is estimated; which in most cases is also okay, but not guaranteed to be exact for certain MP3s) - unfortunately this flag also requires a full scan of the physical file, but is normally absolutely quick.

The 'ASYNC' option allows you to ensure more stable playback on slower devices or when playing multiple files in parallel. This option can actually be turned off in the general settings, section 'General/Audio', set the 'Lookahead Cache' to 'Off' - you might check, if that makes a difference.

So I can only guess, that it must be the 'PRESCAN' option causing the large delay...if you can, you might try to open the file on a faster PC to see, if that makes any difference...

[radio42]

Yes, ProppFrexx can deal with very large files. It even supports the BWF-RF64 file format, which is a .WAV format with over 4GB in size.
I just made a quick test here with a 5 hour MP3 file (encoded in 320kbps) which is 800MB large and it also loaded here instantly and played instantly.
Also CPU load did not increase here.

So I am not sure if things are changing with a 15h MP3 recording...which format is it exactly?
And with which player did you play the file (the PFL Player or the DJ Player)?

A few things in general:
a) when PF is 'idle' it still processes all the mixer channels (even if silent; as these are non-stop mixers - xmplay doesn't use any mixers internally)

b) when you drag a file into the playlist, only the TAGs are being read in

c) In the general settings (see section Meta Data/WaveForm) you can define a WaveForm limit (default is 1800sec. = 30min.) if the file is longer no WaveForm will be rendered
If no WaveForm is rendered, the player do not use/display it and as such you can not use the (empty) WaveForm to scroll/seek in the file - in such case seeking/scrolling is only supported by the scrollbar below! So that is by design.

d) Is 'Auto ReplayGain Calculation' enabled on your machine?
If yes, ProppFrexx would calculate the overall ReplayGain and -Peak value for the file - which might indeed take some time, as it needs to process the whole file in the background.
Same mabe with the Automatic BPM calculation.
Both options also do not exist in xmplay...and are both currently not limited by any setting...(need to think about it, if that would make sense...)

[hdradio]

I tested on a faster pc with mixed results:
If I load the file from the local HD it loads in 8 secs with lookahead 64kb.
With lookahead off it takes about 4 secs.
But when I load the file from a network share it took 120 secs with lookahead 64kb and
80 secs with lookahead off.

On an even more fast pc (my onair pc), it takes about 2-3 secs to load from local HD and 64KB lookahead.

So the problem is when I load this large file from a network share.
When you tested, did you try to load your file from a network share ?

[radio42]

No, in my tests I also loaded it from a local drive (which was actually also an SSD drive).

And from what you are saying, it makes absolute 'sense' and it kind of proves, that it is actually the PRESCAN option I was talking about earlier which makes the big difference in loading time (as xmplay is not using it, as explained).
The ASYNC option (depending on it's lookahead buffer size) just takes a bit of away or adds some extras when dealing with a 'slow' network drive (note, that it is actually not the speed of the network drive, but rather the network IO speed which limit things here).
As said, the PRESCAN option enforces a full file read to ensure an exact duration determination and sample accurate seeking within MP3s, as such 1 GB of data needs to be transferred over the network while loading the file...
How long does it take to copy the file from the network to a local drive...?

So there are 2 options I can think of:

1. Leave everything as is, as the mentioned flags are needed to ensure 100% accuracy:
...and use fast IO sub-systems to read very large files (containing 15h of music
...or live with a longer loading time

2. Add an extra option to suppress the PRESCAN option for very large MP3 files:
...and live with the fact, that in such case sample accurate seeking and exact duration determination is not guaranteed

[hdradio]

Thank you Bernd.
I think that you must comment the Pros and Cons of using the "No Prescan" option so someone can understand if should enable it or not.

[radio42]

Just made a final test here myself using a network drive...and yes, the PRESCAN option is the reason and make the huge difference!
When I remove that flag internally, the streams are also created instantly; but as said exact duration determination and sample accurate seeking can then not be guaranteed.
However, I guess I'll simply add a new 'No Prescan' option to the next release...

[radio42]

Sure! And as with every option, it will always be commented in the ToolTips, which are also available for reading, printing etc. when clicking on the '?' icon at the windows top-right corner.