Waveform Seeker Display ...

[MourningStar]

... not the same when playing a file vs a cd. Should they not be same?

[Eris Lund]

If I had to guess, CDs are a bit special than just your ordinary file

[MourningStar]

If I had to guess, CDs are a bit special than just your ordinary file

different, yes. but not special.

[Aminifu]

Dro would have to provide the details, but I believe it has to do with the input plug-ins. The waveform seeker works with the applicable input plug-in to generate the waveforms. I don't think the input plug-in for CDs provides the necessary info. 

[MourningStar]

... I don't think the input plug-in for CDs provides the necessary info.

I wonder what that info would be ...

[Aminifu]

Hopefully dro will notice and reply to this thread soon. Have you tried the "Re-render waveform"  command in the waveform seeker's context (right-click) menu? I was randomly getting sine waves for my mp3s with beta build 8256 back in July and the re-render command forced the correct waveform to be generated. Dro made changes that fixed that issue in my configuration for the beta builds since then.

[Aminifu]

Hi MorningStar,

If you really want (or need) to see the CD track(s) waveform, there is a work-a-round. Use a CD ripping app to copy and compress the track(s) to the mp3 or flac format. The waveform seeker will be able to generate waveforms for the mp3 or flac.

I use Exact Audio Copy (https://www.exactaudiocopy.de/) to rip CDs. It works slowly, but makes excellent rips.

[dro]

CD entries aren't rendered with how the plug-in currently works as double-accessing an audio CD track for playback & rendering is not a good thing to do. When the status message was being shown in the window (changed to not being shown based on numerous bits of feedback & complaints about it ruining the look of things) then that would show an unsupported message.

For local files it's generally not an issue as long as the plug-in correctly supports multi-access to a file since rendering & playback are being done at the same time (for which not all input plug-ins correctly support that which is why some of the video game formats also don't such rendering).

With an audio CD, that becomes messy quickly & the only 'safe' option would be for me to consider buffering the whole audio track which subject to available memory (another potential issue in itself) would then allow for the dual access that's needed. So that's why an audio cd track is not the same as a local file as despite being a stream of 1s & 0s, getting that data is different with respect to the way that data is read.

-dro

[MourningStar]

Thank you for the reply - Not a showstopper and, upon reflection, I prefer the different appearance as it readily lets me know that a cd is playing. Also, the appearance of streaming content produces a yet 3rd different appearance and is acceptable now as well as I then know it is a url playback stream.

[dro]

It's an annoying inconsistency which would be nice to resolve for more of the cases where it happens & there's scope to get the data. As for streamed formats, that's a different kettle of fish as there's some where it is possible to display it if the render request was allowed to wait a while & then a cached / temp copy of the file (for radio streams it doesn't make sense as there's no end time unless it just offered a rolling output which is something that could be considered) & render from that. Like you say it's not a showstopper so it'll likely stay like it is for the time being

-dro

[Dr.Flay]

In simple terms;
Reading a compressed digital file from a fast storage medium, means it does not risk pausing or stuttering the music due to having to actively scan the whole file at the same time as playback.
Temporarily the player is reading 2 parts of the same file at the same time.

With an audio CD you have large full uncompressed audio on a slow device, thus risking a massive delay with processing.

I think the only sensible way to have waveforms for CDs, would be to have a way to scan the CD before playing, like the way the volume levels are done.

[MourningStar]

.... Like you say it's not a showstopper so it'll likely stay like it is for the time being

-dro

... not to mention that I now prefer it this way (and would likely take issue if it changed!) - 

[dro]

Pre-processing the CD beforehand for playback is maybe a bit excessive since at that point it'd be simpler to just rip the cd (something else that needs to be sorted out).

The options that come to mind are either render things in realtime with the waveform seeker window being able to wait as new data is read in via playback. The other option would be to just buffer the whole track (which is the memory issue I'd mentioned) & then playback / render requests pull from the buffer - this would have the ability to allow the drive to spin down which might be useful in some instances but it then needs handling to allow the next track (more so if playing things in order) to be spun back up ready in time so it doesn't then mess-up.

Either way it's a non-issue for the time being but there's scope to do something towards it.

... not to mention that I now prefer it this way (and would likely take issue if it changed!) - 

Nothing an option wouldn't be able to resolve

-dro