Introducing the New Tonal App

[Timmeon]

Do you like the old version? For the new one, I gave it an anonymous but native feeling. Defining how it works is more important than defining how it looks, at least for the prime time.


This is very important and fundamental. Please understand I need to pitch the more fundamental things (audio format, music metadata, and playback) first because Tonal is so controversial on these topics.


I rarely mentioned subjective sound quality performance except for the last fine note (I quote others for the only fine note). The audio stack, the configuration-free feature, and the low-footprint renderer are measurable engineering decisions: I am not too shy to describe them (again, I will not link that to anything subjective).

• Classical music metadata is a real problem. If you don’t feel the pain, please skip this one.
• Collaboration on music metadata is a real problem, MusicBrainz is born for that (remember the old FreeDB?).
• Keeping a music collection well-organized is a real problem, I have OCD that asks me to reduce entropy at all costs. If your music collection is well-organized without inconsistencies, please skip this one.
• Fixing broken CD rips is a real problem. If you only collect hi-res music or don’t use Macs, please skip this one (CUETools is unavailable on macOS for the time being).
• Accurate playback is a real problem. Have you encountered some $$$ apps that pop/click at the beginning/end of DSD tracks? If not, please skip this one.
• Unnecessary configuration is a real problem IMHO. Please see my above post.
• Data source availability is a real problem IMHO. I want my experience to be powered by transparent and lasting data, especially in the AI era.

There are no more problems I am trying to solve, only these for the initial version.

Thank you.

Apologies if I came across as a bit judgy. It's just my opinion, man!

The old version looks okay. I'd have a UI designer work on the typography. It needs to look fresh and clean, don't ignore trends. Also, I'd say that albums have one element that many folks complain is missing in the digital experience: artwork. Have a designer explore a solution to that problem. Apple has used a few clever examples in the past.

I would argue against your assumption that defining how your app works is more important than how it looks. If it is thoughtfully designed, a user won't feel the need to concern themselves with how it works. It just works, it organizes the data input while presenting only what's relevant to the user, beautifully.

If your target market is exclusive to 'audiophiles', I'd do some research into what actually motivates them to buy in.
My assumptions would be:

• They're motivated by stories. Your bit-perfect, proprietary format optimized for audio, etc. might actually speak to them.
• They want high-end looks. There is a reason streamers can be sold in heavyweight casework with external power supplies, without audible benefit. Aesthetics. A trophy they can listen to. How it looks is important.
• If the above is true, a low price point might actually be a deterrent.

If you're not exclusively marketing to audiophiles, I'd look to broaden your user base rather than focus on an aging population sitting solo in listening rooms (another assumption). Children, partners, friends. Enjoying music is universal. What about a kids' mode? Cap the volume and make the interface big and bright with a library built for them. Would you ever hand your 3-year-old your smartphone with Spotify and expect them to get it? Probably not. Can your partner navigate your library and easily find whatever they enjoy?

TLDR: Make it pretty and broaden the appeal. You don't have to abandon your core principles to do either of those things.

 

[Keith_W]

TLDR: Make it pretty and broaden the appeal. You don't have to abandon your core principles to do either of those things.

"Proprietary format" is the first thing they should abandon. It is a complete dealbreaker. Find some other way to include metadata. Nobody is interested in another format, let alone a proprietary one.

 

[baoshan]

Apologies if I came across as a bit judgy. It's just my opinion, man!

Your points are very concrete. I can only be grateful for such concrete points. Thank you!

The old version looks okay. I'd have a UI designer work on the typography. It needs to look fresh and clean, don't ignore trends. Also, I'd say that albums have one element that many folks complain is missing in the digital experience: artwork. Have a designer explore a solution to that problem. Apple has used a few clever examples in the past.

The old version was designed by an experienced typographer in 2014. For the new version, you can see I put lots of effort into handling details in typography, especially for classical music. Example here and here. Your analysis (and suggestions below) is quite logical and rational. Thank you!

 

[Timmeon]

And the knock that it isn’t beautiful is just silly. It’s a good looking player.

It is not particularly beautiful or unique or innovative, but I don't think it's necessarily bad. Again, just my opinion.

"Proprietary format" is the first thing they should abandon. It is a complete dealbreaker. Find some other way to include metadata. Nobody is interested in another format, let alone a proprietary one.

I agree.

 

[baoshan]

"Proprietary format" is the first thing they should abandon. It is a complete dealbreaker. Find some other way to include metadata. Nobody is interested in another format, let alone a proprietary one.

.tonal audio format is not introduced to include metadata —— it contains absolutely no music metadata. My seven reasons for .tonal are listed in my response to your critique No. 1. Thank you for this suggestion; I will consider it carefully.

 

[kemmler3D]

I think this is overall a very thoughtful project and I respect the commitment to design choices you've made here. I don't know if they're the right ones and I'm personally not that interested in using it (I'm not meticulous about metadata nor do I listen to a lot of classical) but at least there is focus here.

My suggestion as a marketer is to position the .tonal format as a "container" format rather than audio format. From what I can tell it's a container file for lossless audio, not an actual codec. It's been >10 years since any new, useful lossless codec has come out, and with good reason, it's a solved problem.

The .tonal format solves the problem of keeping discs together and linking them to high-quality metadata. You could call it a "library format" or an "archival container" or something. AFAICT it doesn't do anything to the audio itself. So, I would talk about it in those terms, instead of presenting it as an audio format.

I would also be very pessimistic about users' propensity to edit metadata the way you've laid out. Undoubtedly only about 1-10% of users will actually use this feature. Fewer will use it correctly. I would at least create an editor with fields and validation, rather than just give people text to edit.

What happens when the user's DAC doesn't support a given format, btw?

 

[baoshan]

I think this is overall a very thoughtful project and I respect the commitment to design choices you've made here. I don't know if they're the right ones and I'm personally not that interested in using it (I'm not meticulous about metadata nor do I listen to a lot of classical) but at least there is focus here.

Hommage to you, Sir.

My suggestion as a marketer is to position the .tonal format as a "container" format rather than audio format. From what I can tell it's a container file for lossless audio, not an actual codec. It's been >10 years since any new, useful lossless codec has come out, and with good reason, it's a solved problem.

The .tonal format solves the problem of keeping discs together and linking them to high-quality metadata. You could call it a "library format" or an "archival container" or something. AFAICT it doesn't do anything to the audio itself. So, I would talk about it in those terms, instead of presenting it as an audio format.

I marketed it in the wrong way.

.tonal is indeed a container format containing pure FLAC (for PCM) or WavPack (for DSD) blocks generated using the same encoders/parameters. FLAC and WavPack are not only audio file formats but also mature codecs that can compress/decompress audio samples losslessly. My usage is quite legitimate and common IMHO.

Converting .tonal to .flac/.wv is already built into the Tonal app. Conversion is easy and fast because no transcoding is needed.

Using .flac and .wv as the underlying files is technically feasible but suddenly loses the simplicity and the features I listed when replying Keith_W’s question (also conflicts with some concepts of Tonal), which makes me sad.

I would also be very pessimistic about users' propensity to edit metadata the way you've laid out. Undoubtedly only about 1-10% of users will actually use this feature. Fewer will use it correctly. I would at least create an editor with fields and validation, rather than just give people text to edit.

I believe you are right about the statistics. And I am afraid the number will be even smaller later on.

Please have a look at this album/example. The editor is still easier to use (IMHO) for non-classical albums: requiring less accurate pointer interactions (clicking text fields & buttons). Track numbers (01, 02) are the editor’s built-in features: no need to type manually. But I am also pessimistic that fewer would like to learn and use it correctly.

What happens when the user's DAC doesn't support a given format, btw?

As the user switches between different DACs in the leading sidebar, some albums automatically become playable or unplayable (the play button shows or hides). I can see new DACs (even the low-end models) gradually support more formats. I may be too optimistic.

Thanks, again.

 

[kemmler3D]

I may be too optimistic.

I would survey or chat with some typical prospective users about some of these features. I think you may be a bit optimistic about the prospective users for this app.

Active ASR posters are not typical audiophiles for the most part. Does the typical high-res classical listener really understand selecting between sample rates / DAC settings? Or will they just be confused and angry when there's no output mode compatible with a file that worked well on their other player that had resampling?

I think you should interview / survey some more "typical" listeners to get a sense of this.

But I am also pessimistic that fewer would like to learn and use it correctly.

I think the overall idea is fine. Now you just have a UI design problem to make it easier.

 

[baoshan]

I think you should interview / survey some more "typical" listeners to get a sense of this.

Thanks for that suggestion, which is indeed what I need to do!

I can see many ASR users love classical music and deal with music tags seriously. I failed to make them resonate with the way Tonal handles music metadata.

 

[Sashoir]

These are only my opinions, and so could be completely worthless from a market fit perspective.
The "problems" with classical metadata may not be soluble in a universal manner.
Some people listen to "albums" (discs or multi-discs). Some people listen to "works" (e.g. Bax's Symphony no. 3). Some people would treat an excerpt (say, an overture) as part of a larger work, some as a standalone piece. Some might treat an orchestration as a separate work, some as the same, and some as "related" in some sense.
Some people will think of Ricardo Muti or the LSO as "artists" in the way they would think of Black Flag or the Kentucky Headhunters as "artists" in respect of a recording. Some people will think of Orlando Gibbons as the artist in the same context.
I don't think it's common for the same person to think of a Hendrix cover of a Dylan song in the same way as a Bill Evans cover of a Mercer song in the same way as a Carlos Kleiber cover of a Mahler song.
It's not, I don't think, a "back-end" problem: everything can be recorded pretty easily. But rendering these different approaches to metadata in an intuitive, context-aware, navigable way seems like a lot of work for $99/pop.

 

[baoshan]

Thanks for the points! I try.

Some people listen to "albums" (discs or multi-discs). Some people listen to "works" (e.g. Bax's Symphony no. 3).

You can play the whole album, all tracks “Bax”, or just the “Symphony” by tapping different lines. This may not be what you asked for, please continue reading.

Some people would treat an excerpt (say, an overture) as part of a larger work, some as a standalone piece. Some might treat an orchestration as a separate work, some as the same, and some as "related" in some sense.

For those who treat Ravel’s orchestration as a separate work, he/she can verify that in the Composers list:

For those who treat them as the same, he/she can get both just by searching. Please note there are two (sub) genres shown:

• Classical > Instrumental
• Classical > Orchestral

Click any subgenre to filter the albums further:

Some people will think of Ricardo Muti or the LSO as "artists" in the way they would think of Black Flag or the Kentucky Headhunters as "artists" in respect of a recording. Some people will think of Orlando Gibbons as the artist in the same context.

LSO will always be listed under Groups, I hope this is fine. A conductor/pianist (Ashkenazy, Pletnev, etc.) could be listed under either:

• Conductors, when as a conductor
• Artists, when as a pianist

If I understand correctly, searching Muti, Black Flag, Kentucky Headhunters, or Gibbons is easier than browsing when they are already in your head. As an example, when I search Brahms, I can get all the Artists, Groups, or Conductors related to Brahms. I can choose between BPO and VPO in the screenshot below:

everything can be recorded pretty easily

For this album (with only 7 tracks), there will be around 50 tags (composer, title, artists, roles or artists, recording date, etc.) for the information highlighted, which is not easy IMHO. I have to be extremely careful when using a “tag editor”.

Using Tonal Editor is a whole different story: only 16 lines total.

Thanks again. Please let me know if I misunderstood the questions.

 

[Sashoir]

Forgive me, I don't think I was particularly clear. I think the "search" problem is largely solved. I think the "browse" problem is very much unsolved. And search (knowing what you want ab initio) is not a good solution to browsing (knowing what you want when you find it)