Author Topic: Limit file size using BASS_Encode_Start  (Read 16225 times)

veetid

  • Posts: 71
Re: Limit file size using BASS_Encode_Start
« Reply #25 on: 27 Nov '05 - 01:28 »
I am able to get seeking working if I don't return 0 in the LEN in the STREAMFILEPROC... The problem is that I know the size my buffer will be set at, such as 500 megs... I set the LEN to return the filesize, but once I start having to re-buffer the stream thinks it's reached the end of the file and closes itself out....

If I set the LEN to return from STREAMFILEPROC to some really high number, it works... but this doesn't seem right....

I wish there was someway to return 0 to tell it to play forever, but still seek to positions in the stream that had already been reached...

veetid

Ian @ un4seen

  • Administrator
  • Posts: 20396
Re: Limit file size using BASS_Encode_Start
« Reply #26 on: 27 Nov '05 - 17:05 »
I do the seeking by changing the position in the stream manually, so it still works with the buffered STREAMFILEPROC, but there is a delay before it catches up to the change... Anyway you can think around this?  Tell the channel to move to the end of the buffer or something?

You'll probably have to recreate the stream, ie. call BASS_StreamCreateFileUser again.

Btw, regarding the earlier synchronous business, I should've said "the data is fed to the encoder in the same thread as your STREAMFILEPROC is called after the BASS_StreamCreateFileUser call". The BASS_StreamCreateFileUser call is of course running in the thread that you call it from, so there's no intrinsic reason for the encoding to be blocked by it.

I am able to get seeking working if I don't return 0 in the LEN in the STREAMFILEPROC... The problem is that I know the size my buffer will be set at, such as 500 megs... I set the LEN to return the filesize, but once I start having to re-buffer the stream thinks it's reached the end of the file and closes itself out....

If I set the LEN to return from STREAMFILEPROC to some really high number, it works... but this doesn't seem right....

The "return 0 for unlimited length" thing only applies to buffered file streams. With an unbuffered stream, BASS uses the LEN action to check if it's reached the end of the file, so you can just return a very large number to prevent it ending.

veetid

  • Posts: 71
Re: Limit file size using BASS_Encode_Start
« Reply #27 on: 28 Nov '05 - 10:27 »
Do you think writing to a wave file in RECORDPROC instead of encoding will allow the the file to write faster?  Therefore the playback will gradually fall behind and more of the file will be recorded as it's played?

I assume encoding takes more time and is slower writing a file than raw wave in RECORDPROC right?

veetid

Ian @ un4seen

  • Administrator
  • Posts: 20396
Re: Limit file size using BASS_Encode_Start
« Reply #28 on: 28 Nov '05 - 18:02 »
Do you think writing to a wave file in RECORDPROC instead of encoding will allow the the file to write faster?  Therefore the playback will gradually fall behind and more of the file will be recorded as it's played?

It's impossible to write the data any faster than you're receiving it from the recording device. If you want to gradually fall behind, you could play the stream slightly slower.

I assume encoding takes more time and is slower writing a file than raw wave in RECORDPROC right?

Encoding won't make much difference with any half-modern CPU. Besides, if your buffer is 500MB now, how big is it going to be for non-encoded data?

To be honest, I'm thoroughly confused about what you're trying to achieve :D

veetid

  • Posts: 71
Re: Limit file size using BASS_Encode_Start
« Reply #29 on: 28 Nov '05 - 18:26 »
Basically it's a media player that supports Radio and XM devices... When playing, these devices send their music through the soundcard inputs... I record these inputs and play them back and I can modify the sound with my EQ, but also I allow the user to hit pause, and use rewind/fastforward... Just like watching live TV with a Tivo...

There is a set max buffer size... I have it all working with an unbuffered Stream, but I am limited to 10 megs, which is about an 8 minute buffer... After that my resize code becomes too slow and you hear a slight stutter when the file resizes...

I couldn't get much working with buffered stream... To clear the buffer you have to re-create the stream, which takes too long... So it made scanning radio stations impossible... you hit scan, wait 3 seconds, hit scan again, wait 3 seconds...

I'm pretty close... If I can optimize my resize buffer code to get 40 megs working, 30 minutes or so.... I will be happy....

david
« Last Edit: 28 Nov '05 - 18:28 by veetid »

veetid

  • Posts: 71
Re: Limit file size using BASS_Encode_Start
« Reply #30 on: 29 Nov '05 - 09:07 »

And this is what I suggest:
- You CAN NOT use the LAME encoder to gain what you desire...so...
a) Use a memory buffer (e.g. circular)
b) Use "BASS_WMA_EncodeOpen" to encode to WMA format to the memory buffer
c) Use "BASS_WMA_EncodeWrite" to write the recorded wave data to the WMA encoder
d) Create a user stream (like you already did) and read the data back from your memory buffer


I set it up like this, but I had a problem... If I use BassWma.BASS_WMA_EncodeOpen or BassWma.BASS_WMA_EncodeOpenFile and create a WMA file, whether with the File version or with BASS_WMA_EncodeWrite.... If I do not call close on the Encode, it will not play back...

It makes me not be able to use BASS_WMA_StreamCreateFileUser....

I encode a WMA with BassWma.BASS_WMA_EncodeOpenFile and exited my application before I called the EncodeClose... This file play fine in Winamp, WMP, etc.. but if I try to load that file with BASS_WMA_StreamCreateFile it will not play... if you EncodeClose, the file will play...

this makes playing while encoding not possible... the BASS_WMA_StreamCreateFileUser ends itself right away...

note:  I was able to do this with BassWma in BassLib2.1 and it still works with BassEnc... not sure whats going on...

veetid
« Last Edit: 29 Nov '05 - 09:11 by veetid »

radio42

  • Posts: 4574
Re: Limit file size using BASS_Encode_Start
« Reply #31 on: 29 Nov '05 - 13:42 »
Hi Veetid,

I guess I was as confused as Ian with what you where trying to achieve - but now I think I got it.

a) you want to record internet streams (e.g. live internet radio stations)
b) the recorded data should be encoded live to e.g. MP3
c) this encoded data should also be used as a playback-buffer
d) this playback-buffer should be pretty large to allow the user to listen to
- e.g. what was recorded 2 hours ago
- or even to listen was is currently being recorded
- or any data/music inbetween
e) the 'configurable' size of this playback-buffer determines how far back the user can go to listen to what was recorded
f) so the playback-buffer should cover always exactly - lets say - the last X hours of what was recorded
g) this is why you don't want to use WAV, since X hours in WAV are too big to keep on a simple hard disk.

-> All in All a little 'timeshift' functionality like used in HDD-DVD-Recorders...where you can watch the beginning of a movie, which was recorded 30min ago...while the recorder is still recording the end of the movie...
...but with one big difference: you don't want to have any limit to a single music clip.

You want to constantly record an internet radio station and the recorded 'playback-buffer' should always represent the last X hours of recorded music.
So the user can listen to any of the music within these last X hours.

So in essence you have three tasks:
1. permanently record the data and encode it and write it to harddisk
2. cleanup your recorded data (e.g. every 5 minutes remove the oldest 5 minutes)
3. playback task allowing you to play whatever is in the playback-buffer

The main requirement is, that the buffer (which needs to be constantly reorganized) must be an MP3 or WMA file...because of size.

Hmmm - tricky

veetid

  • Posts: 71
Re: Limit file size using BASS_Encode_Start
« Reply #32 on: 29 Nov '05 - 18:46 »
Quote
So in essence you have three tasks:
1. permanently record the data and encode it and write it to harddisk
2. cleanup your recorded data (e.g. every 5 minutes remove the oldest 5 minutes)
3. playback task allowing you to play whatever is in the playback-buffer

The main requirement is, that the buffer (which needs to be constantly reorganized) must be an MP3 or WMA file...because of size.

That is about right... I have it working, but the larger you make the buffer, the longer it takes to resize, take out the 5 minutes in the front... so you start to hear a stutter...

My problem right now is I want to switch to encode with WMA.. I was use LAME, which worked fine... I can't seem to encode WMA and play it back while it's still encoding... BassWma doesn't seem to be able to play a WMA until the EncodeClose is called on it, which is unlike an MP3 which you can start playing right away...

I am pretty sure I did this in BassLib2.1 though and this started happening when I upgraded to BassNet2.2....

Does BassWma's EncodeClose write the header and BassNetWma can't play without it or something?

veetid


3delite

  • Posts: 895
Re: Limit file size using BASS_Encode_Start
« Reply #33 on: 29 Nov '05 - 18:50 »
If you want to gradually fall behind, you could play the stream slightly slower.

This seems the most nearest to what you want to achieve to me!
You play the stream a little slower (eg. 44100 @ 44000) and you get all the functionality you want (seeking, timeshifting).
 

radio42

  • Posts: 4574
Re: Limit file size using BASS_Encode_Start
« Reply #34 on: 30 Nov '05 - 08:05 »
Quote
Does BassWma's EncodeClose write the header and BassNetWma can't play without it or something?

BASS .NET simply calls the native BASSwma functions - so there is nothing going on under the hut. So this is for sure a native Bass2.2 issue!

I have not tested this with Bass2.1 - so I can not say what might have changed.

But let's ask Ian what he can say about it...