# Question regarding sorting of JSON objects
**URL:** https://community.mp3tag.de/t/question-regarding-sorting-of-json-objects/62802
**Category:** Web Sources Discussion
**Created:** [November 20, 2023, 3:19am UTC](https://community.mp3tag.de/t/question-regarding-sorting-of-json-objects/62802 "2023-11-20T03:19:48Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [November 20, 2023, 3:19am UTC](https://community.mp3tag.de/t/question-regarding-sorting-of-json-objects/62802/1 "2023-11-20T03:19:48Z")
Hello everyone in the community.
I'm hoping someone can enlighten me on an odd behavior when parsing JSON data. More specifically, on how objects in an array are sorted when being parsed.
Example:
this [link](https://itunes.apple.com/lookup?country=US&entity=song&limit=200&id=185731554) will download raw JSON-formatted data for an album in iTunes. In the results array, the 2nd object (a track called "Collision Course") refers to a music video. So, if using a WS script for iTunes (like [pone](https://community.mp3tag.de/t/ws-itunes/13478)'s) and querying this album (id 185731554), then track 1 should have the info for "Collision Course". But this title is displayed for track 7 (the last).
The same thing happens if the same link is opened on an online JSON reader. Some sites will render and sort the objects in the same order as they appear in the raw data, while others (like Mp3Tag) will move the object with the data for "Collision Course" to the last position.
So, this is not a bug in the tagger, but since the raw data has no (visible) index in the objects, how/why is this happening?
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [November 20, 2023, 8:37am UTC](https://community.mp3tag.de/t/question-regarding-sorting-of-json-objects/62802/2 "2023-11-20T08:37:34Z")
It's displayed as track 1 on Windows and Mac here. Can you double-check again?
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [November 20, 2023, 2:26pm UTC](https://community.mp3tag.de/t/question-regarding-sorting-of-json-objects/62802/3 "2023-11-20T14:26:05Z")
_Well, this is interesting_......
Additional info:
- Mp3Tag 3.23 in portable mode, on a Windows 10 machine
- pone script unmodified
- print screen(s) are unmodified
I'm reading the raw data in Firefox 119.0.1 in `view-source:https://itunes.apple.com/lookup?country=US&entity=song&limit=200&id=185731554`. Downloading the file (as .txt) and opening it in Notepad shows the same data as the URL.
If I modify pone's script and enable `DebugWriteInput` I get a file (attached), which (in my case) has the music-video object in the last position [7] of the array, whereas in the raw data (in Firefox or .txt file) it's in position [2].
Also, opening the same link on online JSON parsers
`https://jsoneditoronline.org/`
`https://jsonformatter.org/json-viewer`
will also show "Collision Course" in object [7].
Again, I don't believe this is an Mp3Tag issue since it also happens externally. I'm just posting here because the behavior was found while using Mp3Tag.
[\_pone\_album\_input.txt](https://community.mp3tag.de/uploads/short-url/ugnPoO6xUzdsYhicPBIqtugLRNh.txt) (12.4 KB)
I'll try to gather more data and edit this post with my findings.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [November 20, 2023, 3:18pm UTC](https://community.mp3tag.de/t/question-regarding-sorting-of-json-objects/62802/4 "2023-11-20T15:18:39Z")
@Florian
You might recall this previous exchange
> [@On another topic](https://community.mp3tag.de/t/62736/3):
>
> Testing this with id 1078088776 (390849614 was 'fixed' and the last track is no longer 'empty'),
Checking 390849614 again:
Raw data:
tracks are 1-2-3-4
pone script
Please disregard the track 'numbers'; what is important here is the order of track titles.
By the raw data, the 'Lyric Video' is `tracknumber` 4, and is the last object in the array of raw data
my (current) script:
online parser
- object [1] has track 3, as does my script, but in the raw data object [1] has track 1.
Disclaimer: apologies for the explicit content of the pictures. I have no ill intent towards anyone in the community with this post.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [November 21, 2023, 10:25am UTC](https://community.mp3tag.de/t/question-regarding-sorting-of-json-objects/62802/5 "2023-11-21T10:25:24Z")
Can you try changing `[IndexUrl]` and `[AlbumUrl]` to use `https://` and see if it makes a difference for you?
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [November 22, 2023, 1:06pm UTC](https://community.mp3tag.de/t/question-regarding-sorting-of-json-objects/62802/6 "2023-11-22T13:06:47Z")
It does.
I was assuming (incorrectly) that the raw data in the browser (1-2-3-4) and in `DebugWriteInput` (2-1-3-4) were the same dataset when they were in fact 2 different datasets (with the same data, but sorted differently).
> [@Florian](#):
>
> It's displayed as track 1 on Windows and Mac here. Can you double-check again?
And because I double-checked using pone's script for comparison, which also uses `http://` instead of `https://` in `[IndexUrl]` and `[AlbumUrl]`, I was making the same mistake again. As per the [album page](https://music.apple.com/us/album/collision-course-bonus-video-version-ep/185731554), "Collision Course" is `%tracknumber%` 7; but because his script doesn't parse track numbers, Mp3Tag assigns `%tracknumber%` 1 to the first track entry in the raw data, regardless if it corresponds to the _real_ Track 1 or not, which added to my confusion.
So this topic was a case of human error from my part. Apologies.
--
I opened a topic with a question to the community. The question was answered by the community. Thank you Florian for your time and patience. From my part this topic can now be considered answered/solved and closed.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [November 23, 2023, 5:54am UTC](https://community.mp3tag.de/t/question-regarding-sorting-of-json-objects/62802/7 "2023-11-23T05:54:11Z")