# Numeric sorting fails with comma-separated decimal values

**URL:** <https://community.mp3tag.de/t/numeric-sorting-fails-with-comma-separated-decimal-values/71992>\
**Category:** Support\
**Created:** [October 23, 2026, 10:59am UTC](https://community.mp3tag.de/t/numeric-sorting-fails-with-comma-separated-decimal-values/71992 "2026-10-23T10:59:49Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![PlooToN](https://community.mp3tag.de/user_avatar/community.mp3tag.de/plooton/32/8600_2.png) [@PlooToN](https://community.mp3tag.de/u/PlooToN)\
**Post date:** [October 23, 2026, 10:59am UTC](https://community.mp3tag.de/t/numeric-sorting-fails-with-comma-separated-decimal-values/71992/1 "2026-10-23T10:59:49Z")

</div>

I have a custom column named “Диск” (“Disc”) for disc numbers. Its Field and Sort by are both set to `%discnumber%`. The tag values include comma-separated decimals such as `0,5`, `0,6`, and `0,7`.

Steps to reproduce:

1. Add files with those values in `%discnumber%`.
2. Sort the custom Disc column with the Numeric option enabled.
3. Compare the order after disabling Numeric for the same column.

Actual result: With Numeric enabled, the decimal values are mixed rather than sorted by their numeric value. With Numeric disabled, they sort in the expected order.

Expected result: Numeric sorting should place `0,5` before `0,6` before `0,7` (or the reverse when sorting descending). Could Numeric sorting support a comma as the decimal separator?

I have attached screenshots of the incorrect column order and the column settings.

 ![image(2)](https://community.mp3tag.de/uploads/default/original/3X/f/d/fdb909a45e2abcb5278703b126ac0a45bdc2a543.png)

 ![image](https://community.mp3tag.de/uploads/default/original/3X/6/b/6b3a8a1c984e5cf80af81e4338fbc1c359009b01.png)

---

<div class="post-metadata">

**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\
**Post date:** [October 23, 2026, 11:53am UTC](https://community.mp3tag.de/t/numeric-sorting-fails-with-comma-separated-decimal-values/71992/2 "2026-10-23T11:53:55Z")

</div>

AFAIK no number in tags has decimals.  
All mathematical calculations in MP3tag are integer, see e.g. the documentation

> **[Arithmetic Functions - Scripting Functions – Mp3tag Documentation](https://docs.mp3tag.de/scripting/#arithmetic-functions)**
>
> Mp3tag offers various built-in scripting functions, which can be used at various places in the program. | Documentation on Mp3tag's scripting functions. Mp3tag is the universal Tag Editor.

So if you check the `numeric` option, then more or less $num() is applied and that converts all the number parts of a string into a number until it hits a non-numeric character - which is the decimal indicator in this case - and all numbers like `0,5` or `0,6` become `0` and are treated as the same value.

The only way out would be a scripting expression in "Sort by" that converts the decimal number into a sortable string. I don't know the rest of your data so I cannot make a suggestion right now that treats the part in front and behind the comma in the correct way.

The option `numeric` and its effect is also decribed in the documentation:

> **[Editing Columns - File List – Mp3tag Documentation](https://docs.mp3tag.de/customization/file-list/#editing-columns)**
>
> The File List is the main list that lists the files loaded with Mp3tag. While it already provides a range of different columns to display file information, it can be extended and adapted to your needs via View → Customize columns.... | Customization...

---

<div class="post-metadata">

**Author:** ![PlooToN](https://community.mp3tag.de/user_avatar/community.mp3tag.de/plooton/32/8600_2.png) [@PlooToN](https://community.mp3tag.de/u/PlooToN)\
**Post date:** [October 23, 2026, 12:15pm UTC](https://community.mp3tag.de/t/numeric-sorting-fails-with-comma-separated-decimal-values/71992/3 "2026-10-23T12:15:15Z")

</div>

It would be helpful to know whether full support for decimal numbers in Numeric sorting is planned for a future version of Mp3tag.

I understand that workarounds are possible, but native support for decimal values would be a welcome improvement.

---

<div class="post-metadata">

**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\
**Post date:** [October 23, 2026, 12:23pm UTC](https://community.mp3tag.de/t/numeric-sorting-fails-with-comma-separated-decimal-values/71992/4 "2026-10-23T12:23:27Z")

</div>

> [@PlooToN](#):
>
> but native support for decimal values would be a welcome improvement.

That would be a feature request and no bug.

Just to get your current case closer to a solution, I suggest the following expression in "Sort by":  
`$num($regexp(%discnumber%,'(\d+),.*',$1),3)$num($regexp(%discnumber%,'.*,(\d+)',$1),1)`

Also, I would like to emphasize that DISCNUMBER according to the standard also does not know any decimal numbers but only allows the `/` as separator. In general it is treated like a "numeric string".  
Also, please consider that the decimal indicating character is not the same all over the world. So if you get data from other parts of the world, this may confuse such a function.  
The only way around it would be to allow floating point numbers - but those are not mentioned in the tagging standards.  
All these reservations to show reasons behind the current implementation and that it may take a while until you see a different function.  
Until then my suggestion might help you to get better sorted discnumbers.  
I move this thread to #Support

---

<div class="post-metadata">

**Author:** ![PlooToN](https://community.mp3tag.de/user_avatar/community.mp3tag.de/plooton/32/8600_2.png) [@PlooToN](https://community.mp3tag.de/u/PlooToN)\
**Post date:** [October 23, 2026, 12:43pm UTC](https://community.mp3tag.de/t/numeric-sorting-fails-with-comma-separated-decimal-values/71992/5 "2026-10-23T12:43:03Z")

</div>

Thank you for the detailed explanation and the suggested workaround.

I agree that this is a feature request rather than a bug. I appreciate your help!

---

<div class="post-metadata">

**Author:** ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)\
**Post date:** [October 23, 2026, 4:05pm UTC](https://community.mp3tag.de/t/numeric-sorting-fails-with-comma-separated-decimal-values/71992/6 "2026-10-23T16:05:07Z")

</div>

3 posts were split to a new topic: [Provide means to access length of track including milliseconds](https://community.mp3tag.de/t/provide-means-to-access-length-of-track-including-milliseconds/71996)

---

<div class="post-metadata">

**Author:** ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)\
**Post date:** [October 23, 2026, 4:13pm UTC](https://community.mp3tag.de/t/numeric-sorting-fails-with-comma-separated-decimal-values/71992/7 "2026-10-23T16:13:03Z")

</div>

> [@ohrenkino](#):
>
> Also, I would like to emphasize that DISCNUMBER according to the standard also does not know any decimal numbers but only allows the `/` as separator. In general it is treated like a "numeric string".

This is correct, the expected field contents for Track, Discnumber, and their respective Totals fields are integer based. Even if mp3tag was to implement some option to include additional text characters, this would likely break other library managers and players. IMO it would end up being something that would introduce more frustration downstream.

---

<div class="post-metadata">

**Author:** ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)\
**Post date:** [October 26, 2026, 2:23pm UTC](https://community.mp3tag.de/t/numeric-sorting-fails-with-comma-separated-decimal-values/71992/8 "2026-10-26T14:23:15Z")

</div>

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.
