next »

[PhoenixX_2]

BASS_ChannelGetLength(Stream, BASS_POS_BYTE) returns huge numbers with streams loaded while wavpak plugin is loaded.

2147483602 = BASS_ChannelGetLength(Stream, BASS_POS_BYTE)

(stream plays fine otherwise)

I've attached file to test this with.

[Ian @ un4seen]

Did you happen to create the file in memory, using BASS_Encode_Start and an ENCODEPROC? If so, the problem will be that the Wavpack encoder is unable to go back and update the header's length information at the end. Please try using BASS_Encode_StartLimit instead.

[PhoenixX_2]

Yes.

Before I read your message, I was reading on wavpack's documentation and saw the PCM options.  By encoding the data with:

--raw-pcm=freq,bps,ch

It resulted in proper length being reported.  How is this?  Am I doing something hacky now?  Does the data the encoder send be PCM data or is it properly headered?

And I'm not sure I follow BASS_Encode_StartLimit() idea - would I just give BASS_ChannelGetLength(BASS_POS_BYTE)?  How does it give it a proper length?

[Ian @ un4seen]

You can tell BASS_Encode_StartLimit the amount of the data that will be encoded in the "limit" parameter, which it can then put in the WAV header that is sent to the encoder. It you will be encoding an entire file, you can indeed use its BASS_ChannelGetLength (BASS_POS_BYTE) value, unless the stream is floating-point (using BASS_SAMPLE_FLOAT) and you're asking BASSenc to convert it to integer via one of the BASS_ENCODE_FP flags; you will need to adjust the length according in that case, eg. divide by 2 if converting to 16-bit integer.

When you use the "--raw-pcm" option with the Wavpack encoder, you're telling it to ignore the WAV header, so it won't be getting the length (or sample format) from there. When doing that, you should also use the BASS_ENCODE_NOHEAD flag in the BASS_Encode_Start call to tell it not to send a WAV header to the encoder.

[PhoenixX_2]

I understand that using "--raw-pcm" will not use the WAV header, but I'm asking how it gets proper length at that point, since it still won't be able to seek backwards...

[Ian @ un4seen]

When it doesn't know the length (ie. no WAV header), the Wavpack encoder stores -1 as the length in the output file's header. When the Wavpack decoder sees that, it will get the length by seeking to the end of the file and get the length from the final block.

[PhoenixX_2]

Then why not send -1 as the length under regular circumstances?  Or is that not universally accepted?

[Ian @ un4seen]

The length that is stored in the Wavpack header is in samples, so -1 (0xFFFFFFFF) would only be retained if the sample data is mono 8-bit, ie. 1 byte per sample.

When the encoding stuff was implemented many moons ago, I recall -1 (0xFFFFFFFF) was used initially but there were encoders that had a problem with that, apparently because they were treating it as a signed number. So in the end it was decided to use the maximum signed value (0x7FFFFFFF) as the default length, when it isn't specified via BASS_Encode_StartLimit.