Author Topic: BASS.NET API 2.4.12.7  (Read 783434 times)

gabsoftware

  • Posts: 30
Re: BASS.NET API 2.4.0.2
« Reply #400 on: 14 Apr '08 - 17:54 »
As you can see on the email I just sent, v2.4.0.2 changed nothing : It's still NOT possible to retrieve the picture of v2.4 id3 tag unsynchronized, you can try on the mp3 I ent to you last time ;) (PictureCount=1 but nothing is returned for PictureGetImage(0)  )

The help now successfully integrates into VS2008 !  :D


EDIT :

My big apologies, you are right, my software used the 2.4.0.1 (Who said today is version-problem-day ?  ;)) ! All is fine with 2.4.0.2. My excuses ! And thank you because now it woooorks !

Gabriel
« Last Edit: 14 Apr '08 - 18:23 by gabsoftware »

gabsoftware

  • Posts: 30
Re: BASS.NET API 2.4.0.2
« Reply #401 on: 16 Apr '08 - 07:42 »
Hello,

I just experienced something strange :
Some of my mp3 for some reason  have an attached picture of size = 0 byte. That happens for dozens of files on about 5000 files, but that happens. So TAG_INFOS.PictureCount > 0 but TAG_INFOS.PictureGetImage(0) = NULL.
Could it be possible that PictureCount only retrieve the number of valid pictures (eg non-zero byte pictures) ?
Thanks :)

gabsoftware

  • Posts: 30
Re: BASS.NET API 2.4.0.2
« Reply #402 on: 16 Apr '08 - 11:33 »
I also found that the Year field of a TAG_INFO instance is not correctly retrieved for most of my mp3, although it appears to be correctly set. Maybe a problem of unsynchronization again ? ;).

Try to get the year with the attached mp3 in the email I just sent to you :). This happens with both 2.4.0.2 and pre 2.4.0.3.


EDIT #1

I just found that the TYER frame of 2.4 id3 tag is deprecated and the new TDRC (recording time) should be used instead. And the files with the Year field don't working do not have a TYER but a TDRC frame. The windows explorer recognize the TDRC frame.
Could you fix this ? :) (and what about to check the deprecated files in 2.4 and their replacement)

See ya !

Gabriel.


EDIT #2
Another improvement that would be great is : when one field is not found in ID3 v2.x, to search in the other tags (if present) for the similar information (tag id3v1, apev2...)
Then that will reduce the chances of having a unregognized new field and keep some compatibility :)
« Last Edit: 16 Apr '08 - 12:15 by gabsoftware »

riesm

  • Posts: 51
Re: BASS.NET API 2.4.0.2
« Reply #403 on: 16 Apr '08 - 21:17 »
A small waveform question. I have several saved waveform files on my system, that were rendered 16-bit. Now I use a 32-bit rendering (and streamcreate). I assumed that calling SyncPlayBack would make all waveform values valid for the current stream, however markers do not seem to recalculate. See code example below:
Code: [Select]
WF = New Un4seen.Bass.Misc.WaveForm(mTag.URL, New Un4seen.Bass.Misc.WAVEFORMPROC(AddressOf MyWaveFormCallback), Me)
If IO.File.Exists(System.IO.Path.ChangeExtension(mTag.URL, ".wf")) Then
  If WF.WaveFormLoadFromFile(System.IO.Path.ChangeExtension(mTag.URL, ".wf")) = True Then
    DrawWave()
  Else
    WF.RenderStart(True, Un4seen.Bass.BASSFlag.BASS_SAMPLE_FLOAT)
  End If
Else
  WF.RenderStart(True, Un4seen.Bass.BASSFlag.BASS_SAMPLE_FLOAT)
End If
...
sub DrawWave()
If WF.SyncPlayback(strm) = False Then
            Debug.WriteLine(Bass.BASS_ErrorGetCode.ToString)
End If
If WF.GetMarker("Fade Out") > -1 Then
  'endpos from saved files are about half if rendered in 16-bit
  endpos = WF.GetMarker("Fade Out")
End If
end Sub

The WF.SyncPlayBack works perfectly for calculating the wave position to the stream position. However, is there a workaround for calculating the marker's locations? Or, is there a way to know if the loaded waveform is 32-bit, 16-bit or something else, so I can recalculate the markers myself? Any pointers and help is greatly appreciated.

EDIT: I just found the great WF.Syncfactor which allows me the needed calculations. However, the markers are all painted at the wrong location. This can be fixed manually of course, but would it be something that WF.SyncPlayBack should do?
« Last Edit: 16 Apr '08 - 22:06 by riesm »

radio42

  • Posts: 4576
Re: BASS.NET API 2.4.0.2
« Reply #404 on: 16 Apr '08 - 22:53 »
Hi,

that's true.
The stored marker values itself are indeed never converted. So they will always keep the value as you set them.

However, they are converted during drawing the waveform - so that their position reflects the correct position within the graphic according to the SyncPlayback.
This means the SyncPlayback has an effect on drawing the markers only - but not to their native values.

As you are using the markers to 'save' your cue-points for later retrieval and want to ensure, that no matter what stream resolution (16 or 32bit) you are then using with the playback stream, you have to convert the marker values manually.
I can not automatically convert them, since then they might be converted twice:
a) during drawing internally
b) when getting their values
That's why I have to leave the marker values itself in their origin.

But, you can easily convert them manually by using the methods:

"Position2Rendering" resp. "Position2Playback"

These methods simply convert the given position either to the playback channel resolution or the other way around.
They use the property "SyncFactor" which is calculated, when you call "SyncPlayback".

But you can also calculate the factor yourself, by accessing the "Wave.bps" property, which tells you the resolution of the rendered waveform (a 16-bit saved waveform will return 2, a 32-bit saved waveform will return 4 and 8-bit will return 1).

Hope that helps you out.

radio42

  • Posts: 4576
Re: BASS.NET API 2.4.0.2
« Reply #405 on: 17 Apr '08 - 14:36 »
Hi riesm,

I have fiddled a little and now changed the WaveForm Markers and VolumePoints, so that they are internally always stored in the rendering resolution position.
So for example when using AddMarker they will be converted to the rendering position and when using GetMarker the value is converted back to the playback resolution - according to your previous SyncPlayback call.

Here is the version to try out:
www.un4seen.com/filez/4/Bass24.Net_pre.zip

Let me know your findings!

riesm

  • Posts: 51
Re: BASS.NET API 2.4.0.2
« Reply #406 on: 17 Apr '08 - 15:59 »
This is working great and, I think, gives more sense. Thanks for all your hard work!

riesm

  • Posts: 51
Re: BASS.NET API 2.4.0.2
« Reply #407 on: 17 Apr '08 - 16:26 »
I was thinking, since you are 'fiddling around'  ;D, if it was possible to set the waveform rendering priority. I have the distinct feeling that the background rendering is done at normal priority and I would like to change (if possible) to BelowNormal or even low priority. Let me know if this is possible or not. Thx. riesm.

radio42

  • Posts: 4576
Re: BASS.NET API 2.4.0.2
« Reply #408 on: 17 Apr '08 - 16:30 »
Today it's running at: ThreadPriority.BelowNormal
But I might think about adding an additional parameter to set the priority.

radio42

  • Posts: 4576
Re: BASS.NET API 2.4.0.3
« Reply #409 on: 21 Apr '08 - 15:25 »
21.04.2008: Version 2.4.0.3

BassVideo: support for the latest 2.4.0.7 version added
General:
  - WaveForm: Support for ThreadPriority added


BASS.NET:
Full Install:
  www.un4seen.com/filez/4/Bass24.Net.zip

Lib only:
  www.un4seen.com/filez/4/Bass24.Net_update.zip

toda

  • Guest
Re: BASS.NET API 2.4.0.3
« Reply #410 on: 25 Apr '08 - 23:30 »
Hi,
I installed BASS 2.4.0.3 on my PC (VS2008, WinVista). If I press F1 in VS a messagebox appears which says that nothing could be found.
But in the help-window the Filter is "BASS.NET..."

Does anybody know whats going wrong?

drainey

  • Posts: 15
Re: BASS.NET API 2.4.0.3
« Reply #411 on: 27 Apr '08 - 06:19 »
Does anyone know of a way other than the bassvideo addon to play mpeg files. I am not interested in the video part just to be able to play the audio part.

Renegade

  • Posts: 160
Re: BASS.NET API 2.4.0.3
« Reply #412 on: 8 May '08 - 02:47 »
Any chance that you could put back in the gradient colors that used to be in there for the waveforms? They were really nice looking.

The properties were something like ColorLeftPeak and ColorLeftBase if I remember right.


Renegade

  • Posts: 160
Re: BASS.NET API 2.4.0.3
« Reply #413 on: 9 May '08 - 01:51 »
About that last post, a boolean for something like "UseGradient" might be good. It could then use the envelope color as the gradient peak color. That would avoid adding in too many more things or changing the API too much. Just a thought anyways.

radio42

  • Posts: 4576
Re: BASS.NET API 2.4.0.3
« Reply #414 on: 9 May '08 - 08:34 »
I'll take a look at it ;-)

ken

  • Posts: 739
Re: BASS.NET API 2.4.0.3
« Reply #415 on: 12 May '08 - 21:45 »
I have some problems with AAC streaming. I get same result with your "Live Streaming" app.

MP3 streaming works fine, but AAC my Shoutcast Server (Windows 1,9,8) says that "source dropped connection" after a few seconds, the encoder gives no error.

I'm using all the lates Bass versions, and running on Vista.

I've used same code on Bass 2.3 and then AAC streming worked fine.

radio42

  • Posts: 4576
Re: BASS.NET API 2.4.0.3
« Reply #416 on: 13 May '08 - 07:58 »
That sounds...but without any source or error codes it seems, that I can not reproduce the issue here...so could it be something with your network connection under Vista?

ken

  • Posts: 739
Re: BASS.NET API 2.4.0.3
« Reply #417 on: 13 May '08 - 09:46 »
So strange, it works fine today...  Have to more tests on Vista vs XP.




ken

  • Posts: 739
Re: BASS.NET API 2.4.0.3
« Reply #418 on: 25 May '08 - 21:06 »
I'm working with the WaveForm class, and wonder if/how I acn do convertions like "Bass.BASS_ChannelSeconds2Bytes" and "Bass.BASS_ChannelBytes2Seconds" just inside that class without have to do BASS_StreamCreateFile to get a channel.

I want to convert "GetCuePoints" to milliseconds and back from milliseconds to us in "AddMarker".

/Ken

radio42

  • Posts: 4576
Re: BASS.NET API 2.4.0.3
« Reply #419 on: 26 May '08 - 09:25 »
Ypu might use the "Position2Frames" and the "Frame2Seconds". Like this:
Code: [Select]
double pos = Frame2Seconds(Position2Frames(cuein));

ken

  • Posts: 739
Re: BASS.NET API 2.4.0.3
« Reply #420 on: 26 May '08 - 11:19 »
Ypu might use the "Position2Frames" and the "Frame2Seconds". Like this:
Code: [Select]
double pos = Frame2Seconds(Position2Frames(cuein));

Yes that I found out, but from "seconds" to byte, how to I do that?

See I store my cue's as milliseconds in the database and the waveform as byte[]. But when loading back the wavform from DB and using "AddMarker" so set the cue's I don't get the position of markers good.


radio42

  • Posts: 4576
Re: BASS.NET API 2.4.0.3
« Reply #421 on: 26 May '08 - 11:39 »
Code: [Select]
long pos = Frame2Bytes(Position2Frames(sec));

However, all these methods do use an internal 'syncFactor', which is used when calling the "SyncPlayback" method at the waveform. This to translate the rendering resolution to an given playback stream.
This is because when calling "RenderStart" to render a WaveForm an internal decoding stream is created, using the 'flags' specified. However, your playback stream might be created differently. E.g. you render with 16-bits, while you later playback at 32-bit float. That's where the "SyncPlayback" method comes into play.

So when you save or restore your positions you should ensure to call "SyncPlayback" in advace using your real playback stream.

ken

  • Posts: 739
Re: BASS.NET API 2.4.0.3
« Reply #422 on: 26 May '08 - 12:23 »
So when you save or restore your positions you should ensure to call "SyncPlayback" in advace using your real playback stream.


Works fine now, and the SyncPlayBack also helped. Thanks!   :)

Renegade

  • Posts: 160
Re: BASS.NET API 2.4.0.3
« Reply #423 on: 26 May '08 - 23:21 »
Hey Bernd,

Have you given any thought as to whether you can add back in the nice gradients for the waveforms? ;)

(I'll buy another license! :) )

radio42

  • Posts: 4576
Re: BASS.NET API 2.4.0.3
« Reply #424 on: 27 May '08 - 12:46 »
Yes, I was just about to implement it....but...the thing is, that today I draw the channel in one shot (meaning, e.g. the left channel of  stereo waveform is not composed out of an upper half and a low half.
But in order to draw the wave form in a gradient way, I would need to split each channel into 2 halfs (upper and lower, each for the left and the right channel) and draw each half independently. This would almost double the time it takes to draw the entire wave form, which was actually the reason to remove the gradient drawing.

So I am really not sure, if I would like to add it again, since then the drawing would be much slower and more complex.