AssetService:SearchAudio() returns data that you cannot reproduce

Bug Reports Engine Bugs
,
#1

Currently in Clip It we allow users to save Audio. However the audio that they are looking at usually comes from the result of AssetService:SearchAudio(). The issue comes from when a player rejoins, there’s no way to grab the same exact data from the Audio’s ID. For example, there is no way to grab the correct Title or Artist values as they can be different as seen below:
image
image

Repo (this will sometimes work sometimes not, depends on the audio and creator themselves if the names are the same):

local AssetService = game:GetService("AssetService")
local MarketplaceService = game:GetService("MarketplaceService")

local audioSearchParams = Instance.new("AudioSearchParams")
audioSearchParams.AudioSubType = Enum.AudioSubType.Music
audioSearchParams.SearchKeyword = ""

local audioPages = AssetService:SearchAudio(audioSearchParams)
local result = audioPages:GetCurrentPage()[1]
local info = MarketplaceService:GetProductInfo(result.Id, Enum.InfoType.Asset)

print(result, info)

Expected behavior

I would like an AssetService method to be able to grab the exact data per audio asset id.

1 Like
#2

If you are saving the audio asset ids for each player then consider using the AssetService: GetAudioMetadataAsync method. It has higher rate limits than SearchAudio and you can query by id rather than keyword for exact matches.

2 Likes
#3

Thank you! Yeah for some reason at some point we switched out GetAudioMetadataAsync an instead just loaded the data we stored, which was producing bad data. Switched it back to request the audio data with that method and everything seems to be working fine. Thank you!

#4

Hey! I have been using AssetService:GetAudioMetadataAsync and I noticed that for some results, it will be missing the Title field. I was wondering if you knew why?

For example:

print(game.AssetService:GetAudioMetadataAsync({ 7524653769 }))

--[[
{
    [1] =  {
        ["Artist"] = "Emiko_Daitaku",
        ["AssetId"] = "7524653769",
        ["AudioType"] = Music,
        ["Duration"] = 58
    }
]]

print(game.AssetService:GetAudioMetadataAsync({ 1843700415 }))

--[[
{
    [1] =  {
        ["Artist"] = "Salib",
        ["AssetId"] = "1843700415",
        ["AudioType"] = Music,
        ["Duration"] = 222
        ["Title"] = "Creepy"
    }
]]
#5

That should not be happening. I’ll look into this and provide an update when I figure out the underlying issue.

1 Like
#6

That asset 7524653769 be fixed within the next few hours as the caches update. Were you seeing this missing title issue for any other assets?

#7

I didn’t check other assets, I just noticed the one since it was causing errors and made a temporary fix for it

#8

Hey! I just took a look and looks like the sound 7524653769 still does not have a Title field.

#9

I can reproduce the title being missing for that asset. I think this time I figured out the root cause for this issue and will be deploying a fix later today. Sorry for the inconvenience this has caused you and thanks for reporting this bug.

I’ll update this thread when I deploy my changes.

2 Likes
#10

This should be fixed now. Please let me know if there are any more issues.

2 Likes
#11

Hey! I was wondering if there were plans to correct the Duration field for results. I’ve noticed that if you try to request data for an audio that’s < 1 second, it will provide an inaccurate result which in our specific case breaks multiple of our systems.

#12

for reference if you try to get the results for the asset 12221967 it will provide:

{
    [1] =  ▼  {
        ["Artist"] = "Roblox",
        ["AssetId"] = "12221967",
        ["AudioType"] = SoundEffect,
        ["Duration"] = 0,
        ["Title"] = "button.wav"
    }
}

However, if you load the sound itself you can see that the duration is really 0.293

image

This is specifically an issue in Clip It where we need to guaruntee the actual duration of an audio to properly display it in our timeline for users making clips. I also do not think it should be the developers problem to deal with since we are supposed to have an API to deal with this ourselves and it is extremely frustrating to constantly have to be battling with this API.