▲

[siggi]

Ok Chris,
that is what I experimented!

I noticed you are using a newer BASSversion, I am on 2.4.15 .
Soon i'll compare our BassDTS versions and our DTS files.
I've one which gives correct length using BASS_DTS_StreamCreateFile,
others don't.

The functions Getposition and Setpositio don't match the length so.
They are of different sample rates, Maybe this brings the problem...

[Ian @ un4seen]

i can confirm that the FileHandle of a DTS AudioFile is not correctly freed if working with the Bass PluginSystem.
if creating a stream via BASS_DTS_StreamCreateFile then the DTS FileHandle is correctly freed.

I see that's caused by a little bug in the BASS_DTS code here:

    https://github.com/pudding-fox/BASS_DTS/blob/37604669600bcdd64478fdbb5718a47a2f6dd299/bass_dts/bass_dts.c#L117

The SetStream call should be at the end of the BASS_DTS_StreamCreate function instead of the BASS_DTS_StreamCreateFile function. Because it isn't called in BASS_DTS_StreamCreate, that means the file is never closed when using the plugin system.

But I don't think DTS files are generally playable via the plugin system anyway, because they usually have normal PCM WAV headers? So BASS would treat them as normal PCM WAV files and play them itself (producing noise unless you have a DTS receiver to decode it).

[siggi]

Hi Ian,
You are mixing up things!

When using BASS_DTS_StreamCreateFile from the plugin then freeing IS CORRECT!!
Using BASS_StreamCreateFile on DTS blocks the file!

DTS files DO NOT have usually PCM WAV headers!
I have now 5 different DTS files, only one has a PCM WAV Header which when played
with BASS_StreamCreateFile produces only noise.
All others play fine.

With BASS_DTS_StreamCreateFile all play fine, but the returned length is only correct with files
of 44100 sample rate.

Just now I'll post to Chris my latest results.

[siggi]

Hi Chris,

Our Bass_DTS DLLs seem to be the same. I got 2 others from around Internet with
different sizes, both don't work.

I tested my 4 DTS files and yours with both of your demos for their length.
Here the result:

        SampRate/Channels       'plugins'   'dts-demo'
file 1  44100/6 PCM/WAV Header   2:47        2:57
file 2  46000/6                  6:46        6:51
file 3  96000/6                  4:22        4:30
file 4  44100/6                  2:19        2:19   
yours   44100/2                 12:08       12:08

As we see here only the last 2 files with sample rate of 44100 have the same length in both demos.
The first file with PCM/WAV Header and 44100 makes the exception.
the other 2 files with different sample rate show big differencies!
Your file is stereo, don't know why somebody put this into a DTS file...

You can find the first 3 files in https://github.com/pudding-fox/BASS_DTS/tree/main/Media

Resuming:
When I would continue to work with BASS_DTS_StreamCreateFile I would need to solve the problem
withh the incorrect length.
To continue with BASS_StreamCreateFile someone must explain the freeing problem!

Thanks til now to all posters!

[Ian @ un4seen]

When using BASS_DTS_CreateFile from the plugin then freeing IS CORRECT!!
Using BASS_StreamCreateFile on DTS blocks the file!

Yes. To clarify, the "plugin system" means using BASS_PluginLoad to plug add-ons (eg. BASS_DTS) into BASS_StreamCreateFile. When you use BASS_DTS_StreamCreateFile, you aren't using the plugin system (you're using BASS_DTS directly). So it is correct to say that the file locking problem only happens when you use the plugin system (due to the missing SetStream call that I mentioned).

[siggi]

Sorry Ian,
but I still don't understand!

Using the BASS_DTS_StreamCreateFile directly would mean that the SetStream call is already
present in the DLL?
Because in that case the file gets freed...

And what about the incorrect length returned by BASS_ChannelgetLength on a channel created by BASS_DTS_StreamCreateFile?

[siggi]

News for all helpers!

Today beside of many tests I decided to compare bytesize returned from BASS_ChannelGetLength
with the file size, searching for patrons.
For this I deleted the Ape TAGs written before to some of the DTS files.
I made a lot of calculations but I could not find any patrons.

Later on I started my AudioZip and wth great surprise all length and positions were
suddenly correct...

So it's clear what caused the problem working with BASS_DTS_ChannelCreateFile!

Now I have to discover why BASS_ChannelGetLength includes the TAG size to the bytesize.
It should not and does not happen with other formats.

I read that DTS needs APE TAGs Right?
It can also be that they are not correctly written...
But Tagging and deleting works well even with covers.

This did a big turn!

Next I'll try again converting and splitting DTS.

[Ian @ un4seen]

Sorry Ian,
but I still don't understand!

Using the BASS_DTS_StreamCreateFile directly would mean that the SetStream call is already
present in the DLL?
Because in that case the file gets freed...

Yes, as you can see here, BASS_DTS_StreamCreateFile is calling SetStream (which associates the file with the stream), while BASS_DTS_StreamCreate (used by the plugin system) isn't:

    https://github.com/pudding-fox/BASS_DTS/blob/37604669600bcdd64478fdbb5718a47a2f6dd299/bass_dts/bass_dts.c#L117

Basically, you shouldn't load the current BASS_DTS version via BASS_PluginLoad. Only use BASS_DTS_StreamCreateFile with DTS files.

And what about the incorrect length returned by BASS_ChannelgetLength on a channel created by BASS_DTS_StreamCreateFile?

I'm afraid I'm not sure about that. I guess it's one of these calculations that's going wrong, but I'm not familiar enough with it to say which/why:

    https://github.com/pudding-fox/BASS_DTS/blob/37604669600bcdd64478fdbb5718a47a2f6dd299/bass_dts/bass_dts.c#L170
    https://github.com/pudding-fox/BASS_DTS/blob/37604669600bcdd64478fdbb5718a47a2f6dd299/bass_dts/dts_file.c#L252

Today beside of many tests I decided to compare bytesize returned from BASS_ChannelGetLength
with the file size, searching for patrons.
For this I deleted the Ape TAGs written before to some of the DTS files.
I made a lot of calculations but I could not find any patrons.

Later on I started my AudioZip and wth great surprise all length and positions were
suddenly correct...

If the "FALSE" in this line is changed to "TRUE" then BASS will read APE tags from the file, which should then mean they get excluded from BASS_DTS's length calculation:

    https://github.com/pudding-fox/BASS_DTS/blob/37604669600bcdd64478fdbb5718a47a2f6dd299/bass_dts/bass_dts.c#L108

Unread tags could indeed explain length calculation problems with some files, but these ones you linked earlier don't seem to have any tags:

    https://github.com/pudding-fox/BASS_DTS/tree/main/Media

Are you suddenly getting the correct length for them too?

[siggi]

Hi Ian,
Ok I now understand the plugin system better.

I added before myself the Ape TAGs also to files from pudding-fox and later deleted them
with a tagging library that I use for Ape files and wav too without any problem.

Now I get the exact length for each DTS even for that with a pcm/wav header!
That's ok. I still load the BASS_DTS version via BASS_PluginLoad.
As you recommend I will stop doing this.

If the "FALSE" in this line is changed to "TRUE" then BASS will read APE tags from the file, which should then mean they get excluded from BASS_DTS's length calculation:

How could I do this?
I have no access to the DLL and I'm Delphi User.
I opened all links you supplied

Maybe I could use the offset in BASS_DTS_StreamCreateFile with the TAG size,
but then I must read the TAG before creating the stream...

[Chris]

So here is a New Compile (C++13)  for testing.
I have modified the Suggests from Ian.
1:) adding the missing "file.SetStream" Call so if you are now working with the Plugin System, now the DTS Stream will freeing fine.
2:) Changing the  "bassfunc->file.Open(mem, file, offset, length, flags, FALSE);
  to  "bassfunc->file.Open(mem, file, offset, length, flags, TRUE)
  so that the StreamGetLength Function will APE-Tags excluded from BASS_DTS's length.
So test it and let me now if all now will working.

[siggi]

Hi Chris,

That sounds great!
I can test it this evening.

So, are you the creator of BASS_DTS?

[Chris]

No I´m normally a Delphi Coder.(started 1998 with Delphi 4)

It's not a big deal to download the C++ source from git, make the changes of 2 Lines and recompile it.

[siggi]

Hi Chris,

Party time!
I can't thank you enough for the new DLL!
And the same too for Ian's great help!

I could not have solves this by my own.

Everything playing DTS now works perfect!

I still have some problems with converting DTS to APE and the predicted output sizes
for conversion in general.
But I think I can solve this! Still work left with the DTS support...

Thanks to you all, great job!

[Ian @ un4seen]

Good to hear those little changes fixed your troubles. I'll try contacting the BASS_DTS developer to get them made official.

[siggi]

Back again,
having still troubles with DTS!

I called too early for party time  !
The byte length returned from BASSS_Getlength is truely NOT correct for DTS.

This needs a longer explication...

I did not recognize it at first, just seeing the supposed correct play time..
But the play times are not real!

I first was confused after encoding to MP3 and getting their play times longer as those of
the DTS files.
So finally I decided to measure the real play time of each file by using a timer and displaying it
in format H:M:s.ms and comparing it to those from other players too.

The results are very interesting:
AZ = AudioZip(my App)
VLC = Win10 version
BS = BSPlayer Win10 version

        SampRate/Channels               AZ displayed  AZ measured diff./s.ms  VLC    BS
file 1  44100/6 PCM/WAV Header   2:47.021        2:46.640          ok            2:47   2:47
file 2  46000/6                                 6:45.600        6:52.219           6.619       6:52   6:45
file 3  96000/6                                 4:22.048        4:26.250           4.166       4:26   4:22
file 4  44100/6                                 2:18.507        2:37.828          19.321  !!  2:38   2:18
file 5  44100/2                               12:08.084       12:07.625          ok         12:08  12:08

Resuming:
There are no problems with file 1 + 5 ! Some milliseconds Don't matter.
The measured play times are notably different for the other files!
VLC handles them well, displaying and progress bar correct!
BS shows the wrong play times as AZ does, and both keep playing on the complete files after
the progress bar has reached the end!
This behaviour I had not noticed before, took a lot of research and trying to get these detailed dates.

So the channel created by BASS_DTS_StreamCreateFile containes the complete bytes as playback is complete.
The GetLength function does NOT return the correct byte length, as my Progress Bar receives the
length as maxvalue and so the progress indication is not correct! The same for the diplayed play time!

Besides the wrong indication of play time, the problem gets even bigger for converting and splitting DTS.
BASS_EncodeStartLimit can not be used as the calculated limit is wrong! Files got cut!
The Ape codec (mac.exe) gave a valid file when giving half of the byte length as limit.
Giving the full length as limit returns invalid APE files.
BASS_EncodeStart does it well for all codecs but the Ape codec still not works!


I tried all possible modes and flags and even updated BASS, bassenc, and bassmixer to the latest versions.
Tried some new flags too.
No difference between using the plugin system or not, using BASS_DTS_SteamCreateFile or
BASS_StreamCreateFile.

Well, I'm stucked again!
Any suggestions?

[siggi]

I just created an issue in pudding-Fox.
https://github.com/pudding-fox/BASS_DTS/issues/1#issue-3882086798

Hope i'll get any response!

[siggi]

Thanks again Chris,

for joining the issue!

[Chris]

So, the BASSDTS Developer has Fixed the "Length" Error.
Here is a new Compile. I have tested it with different Files looks good.

[siggi]

Hey Chris,

You are the best! 

I'll test it this afternoon!

[siggi]

Hi again,
Just tried the new DLL

Yes, the length is now correct for all files!
But, I have new problems now with advancing playback with my progress bar!

Just wrote to pudding_fox and explained it there.
It's really weired as there are only envolved Get/SetPosition functions which worked fine
before the last changes made on Bass_DTS!

There must be more to do, I am more and more confused with that DTS format,
but I'm not a specialist in that audio format!

Pudding should solve that!