Bug AudioClip.Length is incorrect when loading from WebRequest GetAudioClip

I think this is a potential bug to report, but I want to sanity check that I am not doing anything wrong first.

I have a bunch of mp3 files in the StreamingAssets folder (trying to keep the build size down for Android).

When I load them via:

Code (CSharp):

1. var webRequest = UnityWebRequestMultimedia.GetAudioClip(fileUrl, AudioType.MPEG);
2.             yield return webRequest.SendWebRequest();

The clip length is 2x the actual length.

When I put them in Resources and load via:

Code (CSharp):

1.  var clip = Resources.Load<AudioClip>(fileUrl.Substring(0, fileUrl.Length-4));

The clip length is correct.

I've tried AudioType.MPEG and AudioType.UNKNOWN.

I've tried to sequence these audio clips by either checking clip.length and waiting that amount of time or by checking AudioSource.IsPlaying but even the IsPlaying returns true for the double amount.

Sooooo. Is this a bug? Should I be using a different method here either for loading or for storing?

I've attached a zip file of the mp3 in case the compression/etc isn't supported. It comes up as Vorbis under Unity's compression format.

 

I also face same issue.
I try to download audioclip via UnityWebRequestMultimedia.GetAudioClip
The result of AudioClip.samples and AudioClip.length are twice than those that I expected.

It seems that this behaviour is WebRequest Bug.

Code (CSharp):

1.  public static async UniTask<AudioClip> GetAudioClipFromWWW(string uri, CancellationToken token = default)
2.         {
3.             AudioType type = AudioType.WAV;
4.             if (uri.Contains(".ogg"))
5.             {
6.                 type = AudioType.OGGVORBIS;
7.             }
8.             else if (uri.Contains(".mp3"))
9.             {
10.                 type = AudioType.MPEG;
11.             }
12.  
13.             using (UnityWebRequest www = UnityWebRequestMultimedia.GetAudioClip(uri, type))
14.             {
15.                 await www.SendWebRequest();
16.                 if (www.isNetworkError || www.isHttpError )
17.                 {
18.                     Debug.Log(www.error);
19.                     return null;
20.                 }
21.                 else
22.                 {
23.                     AudioClip myClip = DownloadHandlerAudioClip.GetContent(www);
24.                     Debug.Log(
25.                         $"[Audio] ClipData Fs:{myClip.frequency}[Hz], {myClip.channels}[ch] Sample:{myClip.samples}, Len:{myClip.length}");
26.                     return myClip;
27.                 }
28.             }
29.          
30.         }

This bug can be reproduced Unity2019.4.9f1 and Unity2018.4.22f1

 

@UnityMaru

I've already made bug report on 30th, March

https://fogbugz.unity3d.com/default.asp?1325580_5kivb2tvs9o64e4q

I'm afraid that title was too long to view, it may be cutout...
and There are still no action on this bug report...

 

Same Issue on 2020.3.15f2 and 2020.3.16f1.

 

I'm seeing lenth = zero in 2021.3.0f1

 

same in 2020.3.30f1

 

This bug is still active and its fun to deal with. I had to go back into the project and update some audio files. Seems as though the updated files are not double length but the old ones are and I'm not sure what is difference as the frequency/channels are the same. Bitrate on the mp3 files are different so that could be something to do with it? Just not sure how to catch that on the unity side as all properties seem to be the same.

https://issuetracker.unity3d.com/is...imedia-dot-getaudioclip-from-firebase-storage

 

for me in 2021.2.3f1 the length seems to be roughly 1/3rd of the source file

 

> The result of AudioClip.samples and AudioClip.length are twice than those that I expected.

I am facing this issue still in 2022.3.2f1.

You can find a test project here: https://github.com/achimmihca/UnityAudioClipMp3WrongDuration

Will open a new bug report.
Underwhelming as usual.

 

Just discovered this bug in 2022.3.4f1

The generated audioclip Lenght and Samples value is always 0 on the WebGL build

 

> Will open a new bug report.

Unity just confirmed the bug (IN-47586). Hopefully they will fix it in a future release.

 

You are a savior. I had fixed this manually, but I faced another issue.

Code (CSharp):

1. public IEnumerator GetAudioClipUniversal(string fullPath, float percentageOffset, bool isLooping, bool playImmediately)
2.     {
3.         using (UnityWebRequest www = UnityWebRequestMultimedia.GetAudioClip($"file://{fullPath}", AudioType.MPEG))
4.         {
5.             yield return www.SendWebRequest();
6.  
7.             if (www.error == null)
8.             {
9.                 UnloadMainSong();
10.                 song = DownloadHandlerAudioClip.GetContent(www);
11.                 int channels = song.channels;
12.                 int frequency = song.frequency;
13.                 float[] allSamples = new float[song.samples * channels];
14.                 song.GetData(allSamples, 0);
15.                 song.UnloadAudioData();
16.  
17.                 // Audio clip is downloaded with a lot of leading zeros, we remove them manually...
18.                 int lastIndex = Array.FindLastIndex(allSamples, b => b != 0);
19.                 song = AudioClip.Create("song2", (lastIndex + 1) / channels, channels, frequency, false);
20.                 song.SetData(allSamples[0..lastIndex], 0);

Turns out creating float[] array = new float[size] creates "Empty fragmented heap space" that does not free up. So every time I load a song, around 100Mb of RAM is lost, after a handful song loads I run out of RAM and app crashes... I'll take a break and wait for the update to roll out.

 

Were you able to fix it? I came to the conclusion that the problem is in the audio files themselves. But of course, Unity also does not work correctly.

 

I had a similar issue using MP3 files, but it turns out that it was caused by using a variable bitrate encoding. Re-encoding using a constant bitrate fixed the issue. I know this is mentioned in other threads on this forum, but just posting here in case anyone else finds this thread looking for answers with the same issue I had.

 

I managed to find a workaround to this bug. I had the issue where the end of my .mp3 file was being cut off by 'UnityWebRequestMultimedia.GetAudioClip(mp3audioPath, AudioType.MPEG)'

Using the more primitive method from this forum post worked for me: https://forum.unity.com/threads/how...and-make-it-stay-compressed-in-memory.960910/

Here's a code example of the solution. In GetMp3Audio I pass it the data for the mp3 then I load it and I can confirm it plays the entire mp3 correctly.

 public void GetMp3Audio(byte[] mp3Audio)

    {

        string filePath = System.IO.Path.Combine(Application.persistentDataPath, "output.mp3");

        System.IO.File.WriteAllBytes(filePath, mp3Audio);

        var path = "file:///" + Application.persistentDataPath + "/output.mp3";

        StartCoroutine(PlayDownloadedAudio(path)); 

    }



    private IEnumerator PlayDownloadedAudio(string mp3audioPath)

    {

        var dh = new DownloadHandlerAudioClip(mp3audioPath, AudioType.MPEG);

        dh.compressed = true;

        using (UnityWebRequest wr = new UnityWebRequest(mp3audioPath, "GET", dh, null))

        {

            yield return wr.SendWebRequest();

            if (wr.responseCode == 200)

            {

                PlayClip(dh.audioClip);

            }

            else

            {

                Debug.LogError("Error");

            }

        }

   }

I was stuck on this for hours, so hoping it helps someone P.S. If you use Play.HT this is the solution you should use after downloading their audio.

Using 2022.1.23f1

 

I'm still seeing this behaviour in 2023.1.3f1. Which version did the fix go live in? Thanks

 

Thanks for taking time to respond. Much appreciated.

At present I've hacked a workaround of multipying the length * 0.5f for a list of all my audio files known to have this issue, since I already know what files I'm playing. I mention this in case it helps others.