Messages

31

Questions / Re: Issues when analysing / writing replay gain tags of my FLAC archieve

« on: April 28, 2019, 11:54:10 AM »

I only know of Ctrl-Shift-V, which is what I use.

32

Questions / Re: Issues when analysing / writing replay gain tags of my FLAC archieve

« on: April 28, 2019, 09:45:41 AM »

Ok thanks, that bringt it to the point.

33

Questions / Re: Issues when analysing / writing replay gain tags of my FLAC archieve

« on: April 28, 2019, 08:30:44 AM »

Thanks for your reply, I use MusicBee.

But sorry, you didn't answer my question, see in bold.

For me is all clear except the point what value shall I dial-in after the warning that for some titles distortion might happen.

34

Questions / Issues when analysing / writing replay gain tags of my FLAC archieve

« on: April 27, 2019, 09:37:02 AM »

Hi,

I am facing some problems when performing volume analysis to write replay gain tags.
I have a big music archive, volume normalization takes quite some time.

After the replay gain analysis I feel like alone with a huge list in a tiny window
where it's nearly impossible to browse through all titles to get an overview which adjustment I have to perform.

Why is it not possible that MusicBee finds a proper value for adjusting the replay gains up or down on it's own ?

I am aware of that we are not peak level optimizing, that we talk about something like subjective perceived loudness.
But still there is the question, when seeing all the different adjustment values, what final adjustment do I need to perform ??

Proposal: additional sortable colums for title and album replay gain tag adjustment would support the review process.

I see that foobar2000 for example 1st analyses and then writes the replay gain tags.

Wouldn't it be better for MusicBee to 1st gather the max level and loudness of all titles and then coming to conclusions to which common loudness all titles could be led ? At the end we write replay gain tags per title.

If the music material is very different I could think of it's tricky to get both .. a common loudness for all titles on one hand and on the other hand not come over 0dB for each of the titles.

But somehow I have the feeling that this should be solveable by algorithms and not letting the user alone to adjust something where he can not really oversee what to do .. because nobody tells him exactly which value to take or what makes sense.

Foobar2000 also claims to be more precise when using oversampling (to increase sample rate by x2, x4, ...).
Would maybe be also a nice idea to make this analysis more thorough.

Any thoughts or recommendations to this to make this process better ?

Many thanks

35

Bug Reports / 3.3 6904: still issues with sample rate changes (ASIO driver)

« on: January 06, 2019, 02:16:27 PM »

Hi,

happy new year.

There is still a major problem if you want to play FLAC files of different sample frequencies using an ASIO driver.
I reported it alreay in another thread 1 approx 6 months ago, but no fix so far.

In contrast with that with Foobar2000 no problem.

Problem description:
When you play a new song with a significatly higher sample frequency, i.e. from 44.1 to 88.2 then the sample rate
becomes changed from 44.1 to 88.2 kHz, but MusicBee plays at the wrong speed most likely as it it would be still
44.1 kHz as it plays veeeeery slow / deep.
The same effect if you change from much higher to much lower speed.
Nothing bad happens if you change from 44.1 to 48 and back or change between 88.2/96 or 176.4/192 kHz.
Only workaround is to close MusicBee, open it and then voila, it plays 88.2.

This is the case now since a few releases and has not been fixed yet :-/
Thats very sad as I have lossless content of different sample rates: 44.1, 48, 88.2, 96 and 192 kHz.
and I need to work with the ASIO driver in my setup.

Hardware and driver in use:
Windows 7 SP1 Professional, 64 bit.
RME ADI-2 Pro FS BE connected via AES to RME UFX+
Clock Master is RME UFX+, ADI-2 Pro FS gets clock from UFX+ via AES.
RME ASIO driver: MADIface 0.9680 (latest)

With foobar2000 v1.4.1 release (using same HW, driver, signal chain) no issues.

Wouldn't it be worth to spend a few brain cycles trying to fix this?
I think it would be worth if MusicBee would work flawlessly with ASIO drivers like foobar2000.

Many thanks
Andreas

36

Bug Reports / Re: 3.1.6512: distortion when playing audio with much different samplerates via ASIO

« on: July 01, 2018, 08:55:22 AM »

Thanks for the pointer, will try the new ASIO DLL.

I am using 3.2.6699 with still the same problem.

37

Bug Reports / Re: 3.1.6512: distortion when playing audio with much different samplerates via ASIO

« on: June 30, 2018, 07:26:39 AM »

Maybe distortion was the wrong term. The "kind of distorted" sound that you get when playing back with the wrong sample rate.

As I stated in my 1st post clearly this happens when your music titles have a big jump in Sample Rate. i.e. 44.1 to 88.2.

It has nothing to do with distortion that you get when hitting the 0db mark.

Thanks, but you are solving other issues with your kind hint, that is not the case here.

38

Bug Reports / Re: 3.1.6512: distortion when playing audio with much different samplerates via ASIO

« on: January 05, 2018, 04:32:19 PM »

I have this issue as well.


I found its related to the sound card and higher sample rates. My device supports upto 96 driverless, and 192 with drivers, but when playing asio 192khz I get crazy distortion, then when I play 172khz I get distortion as well. When I play 96 then play 172 it plays fine (I think the device is down sampling it since it doesn't support it)


I'm not entirely sure this is musicbee's fault, since all <96khz works no mater how fast I change songs, sounds more hardware related.

Cross tested with foobar2000. There I had zero issues as I wrote. So its not the ASIO driver at all for me.

39

Questions / Re: Random Tempo Changes Between Tracks

« on: January 03, 2018, 06:27:11 PM »

I have also issues with that and made interesting observations which I described in this thread with an updated summary in the 1st post.

https://getmusicbee.com/forum/index.php?topic=23617.0

I have a certain suspicion that there could be a relashionship with the ASIO buffersize to this problem.

If you make only small changes of sample rate, then nothing bad happens, i.e. from 44.1 to 48 kHz or from 88.2 to 96 kHz.
The mess starts when making big jumps, i.e. from 44.1 to 88.2 or higher to put only one example.

What I know is, that the ASIO driver needs to double the ASIO buffersize between 44.1/48 and 88.2/96
and further double when switching up to 176.4/192 kHz as otherwise the buffer is too small.

Could it be the case that the automatic change of ASIO buffersize by the ASIO driver is somehow related to this problem ?
That perhaps the sample rate change by MusicBee needs to "initialize" ASIO in a different way.
A little bit more delay or other parameters ... ?

40

Bug Reports / Re: 3.1.6512: distortion when playing audio with much different samplerates via ASIO

« on: January 03, 2018, 06:21:43 PM »

Thanks for the info, good to know that I am not alone with this issue.

41

Bug Reports / Re: 3.1.6512: playback of audio files with sample rates >48 kHz leads to distortion

« on: December 21, 2017, 02:17:03 PM »

Strictly from a technical interested point of view, and not to discredit your request:
What specifically would mess-up your workflow or results if you would set MusicBee to use Wasapi for your ADI-2 Pro?

https://en.wikipedia.org/wiki/Audio_Stream_Input/Output

ASIO drivers are high quality drivers developed by the vendor for a particular sound card up to recording interfaces being used in studios which can have plenty of inputs and outputs and of different type (analog, digital: ADAT, AES, SPDIF, MADI, ...)

By using ASIO drivers an application is able to directly access the audio hardware with nothing in between.
The advantages:
- less subsystems in between the application and the hardware
- lower latency
- no quality degradation by Windows sound infrastructure
- bit perfect transmission
- optimum performance (highly optimized driver for the particular sound device)

The windows sound system is known to add latency and to alter the content by not being able to fully accurately process the audio.
The only driver model with Windows which has more quality is WASAPI but only in a special mode, which I think is the so called kernel mode.

But I personally do not want to use WASAPI stuff, as I have for my devices high quality ASIO drivers, so to say "the real thing".
WASAPI is nice for audio hardware that has no ASIO driver, agreed. But if you have an ASIO driver its best practise to use this.

For me (using RME recording devices and converters) an ASIO driver has additional benefits: while listening to Music using MusicBee with the RME ASIO driver I can additionally make use of the RME analysis toolkit called DigiCheck. Some of these tools included are described here on the RME page: https://www.rme-audio.de/en/support/techinfo/totalyser.php

But I can only make use of them when I playback audio in MusicBee using the RME ASIO driver. Then DigiCheck can read this audio stream as the ASIO driver is prepared for "multi-client" operation.

Looking at the output of some of these tools is useful for me if I want i.e. compare my mixed and mastered music with some other music which I regard as a "reference track". Or simply to watch it while listening / enjoying music.

And now please lets again concentrate on ASIO and my bugreport, thanks.
If you want to discuss advantages of this over the other protocol, then please open a thread in another subforum.
This makes it also easier for Steve to get the relevant information out of this thread without having go though many lines of text which have nothing to do with the bug report itself.

Update: I updated the start post with latest status. From now on I will update new / relevant findings to the start post,
to make it easier for Steven to find latest relevant information to this bug report.

42

Bug Reports / Re: 3.1.6512: playback of audio files with sample rates >48 kHz leads to distortion

« on: December 21, 2017, 12:39:53 PM »

I would really appreciate if the people behind MusicBee and its ASIO driver would take a deeper look:

Just to clarify: there are no "people" behind MB. It is developed and maintained by one person - Steven. He does this in his spare time and asks for nothing in return. Users who offer him money as an incentive to fix something are wasting their time, and will more than likely get ignored. Users who badger him to fix/add things will also likely get ignored. Users who bump their issue every six hours are likely to be ignored. Steven implements new features and fixes bugs as he sees fit. With the complexity and time involved being key factors. Note that I don't speak for him but I just wanted you to have a fuller understanding of who is behind MB and how he operates

Thanks for clarification. I was aware of that he is the key person but didnt know how the actual status is, because I had no time to track this forum much.

What you all do here, and which is highly appreciated, I do in other forums around recording and also in the RME user forum.

Steven was in the past already much helpful and fixed something in the selection of output devices for ASIO devices with a lot of output channels.

And now I simply hope that he has time and interested to fix this as well.

Its only a hope. And when Steven would speak up we could also talk about a donation, but then based on success.

I am the kind of guy that also spends and spended a lot of private time for free, so dont tell me about that ;-)
I am best familiar with that concept

If Steven says no to this, ok ... then I have to live with it.

As you might have noticed I addressed Steven in my start post as I thought already that he is "the man".

43

Bug Reports / Re: 3.1.6512: playback of audio files with sample rates >48 kHz leads to distortion

« on: December 21, 2017, 10:48:28 AM »

if it would be the driver then it would cause issues also with foobar2000, but with foobar2000 all is fine.

Not necessarily. In very simplified terms, the stream of data being fed into the driver has a source, and not all source/driver combinations get along. Incompatibilities often manifest as a digitally distorted audio stream, such as the one you described. If MB was the source of the problem, large numbers of other users would be experiencing the issue as well, and that simply isn't evident in the forums. So, it's more likely that the issue is unique to your setup. This is why the driver is suspect, most users of the hardware you have are not using MB so the driver probably isn't used with MB often.

Please note that I've taken time out of my day to offer assistance. If you are going to dismiss a simple and basic troubleshooting step out of hand, you're not as likely to receive additional assistance from others here. We're all volunteers, including the developer.

EDITED, pls re-read

I appreciate help but please stick to the topic ASIO.

I would highly appreciate, if Steve as MusicBee owner would take this as an opportunity
to fix a long standing bug in the MusicBee ASIO code.

I think it has not been detected for a long time because the combination of users using ASIO driver
in combination with higher sample rates than 48 kHz is appearently rare.

Steve fixed already some years ago another nasty bug around ASIO driver, for which I am very thankful.
If a recording device has many output channels then a scroll bar was missing to be able to scroll down.

From this I learned that Steven tries his best to make MusicBee to a round product which
works for everybody even if its maybe the minority of users. That spirit is highly appreciated.

Today I made some other interesting findings:

If I preselect 88.2 or 96 kHz in the ASIO driver and then start MusicBee
AND only play music content with 88.2/96 kHz then playback stays stable !

Asynchonity/Distortion happens again, when I switch to 44.1/48.

Isn't it strange ?

If you stay with your music playback within certain sample rates like "44.1/48" or "88.2/96" then all works.
But if you switch playing back from "44.1/48" to "88.2/96" or vice versa, then problems arise (asynchronity/distortion).

Sadly I am not so deep in programming and especially not using Steinbergs ASIO library.

But I have a certain gut feeling that it might be related to the ASIO Buffersize.

The ASIO driver has to change its ASIO buffersize along with higher sample frequencies. This change is being done and HAS to be done by the ASIO driver automatically, because with 88.2/96kHz you transfer double the amount of data.

When I configure the ASIO buffer size (possible from 32 to 2048 samples) to lets say
128 samples @44.1/48 kHz then it will be
256 samples @88.2/96 and
512 samples @176.2/192 kHz.

Has MusicBee perhaps a problem with than or is the code not prepared for this change which has to happen ?

That is at this moment the only explanation which comes to my mind,
as MusicBee has no issues to playback 88.2/96 and also 192 when it has been preselected in the ASIO driver
BEFORE starting MusicBee itself.
Problems start again when switching from 88.2 or 96kHz back to either 44.1/48 or 192 kHz.

Is this perhaps something with which you could find out and fix, why MusicBee has issues and foobar not ?!

If you have a development snapshot, then I am willed to test and to report to the development.

44

Bug Reports / Re: 3.1.6512: playback of audio files with sample rates >48 kHz leads to distortion

« on: December 21, 2017, 10:15:43 AM »

Nice dac tubescreamer!

The asio component that BASS (MB's audio-engine) is using, is already a few years old, and doesn't seem to get a lot of support or updates.
Not sure if the cause of your well-explained issue is related to that, but it might.

A thought: have you tried the asio4all driver?
It's manufacturer-independent, but even some manufacturers 'that can't be bothered' to improve their asio drivers point to it.
(not that I would suspect RME of doing such?)

You'll have to wait and see if MusicBee's developer sees something in your report that would get him interested to investigate this.

My computer is being used in a Home recording studio.




To use asio4all is not an option for me.
I have devices which all have ASIO drivers.
Basically I am using an UFX+ and the ADI-2 Pro is being used solely as Headphone Preamp.

To sum up the situation.
MusicBee has an ASIO driver.
It works very well for 44.1/48 .. only the change to higher sample rate doesnt work.
Other products like foobar do not have this problem.
I very much doubt that this is a problem on my side, be it OS or RME ASIO drivers.

What I am asking for is, that somebody who actively develops MusicBee to look, whether he can maybe change something in the programming, that this problem goes away.

45

Bug Reports / Re: 3.1.6512: playback of audio files with sample rates >48 kHz leads to distortion

« on: December 20, 2017, 09:18:00 AM »

Hi CritterMan,

if it would be the driver then it would cause issues also with foobar2000, but with foobar2000 all is fine.

I prefer ASIO to achive bit perfect transport of audio material to RME and then High End Hi-Fi.
I don't want to discuss ASIO vs WASAPI, I simply want to use ASIO.

Another important finding.

Playback of music with sample rates >48 kHz with MusicBee works, when I
- terminate MusicBee
- change the sample rate to i.e. 96000 in the driver settings dialogue
- start MusicBee again
- start playback of audio with 96kHz

It looks to me that on the change of the sample rate MusicBee seem to do someting wrong.
Maybe something like a timing issue.
In the RME driver setting I can see that the proper sample rate is being set.

But this is tedious work having to quit music bee every time and manually set the samplerate for the audio device
when i.e. the sample rate inside of a playback list changes or when I simply pick such a song with other sample rate.

I would really be glad if MusicBee could be brought to the same good shape in terms of ASIO playback as foobar2000.

Of course I can support with testing.

Many thanks