Hi
I don't know if this is expected or not, but if I rip an audio CD and then remove the files from the destination folder (for whatever reason) using "rm" or "mv", I can't rip the same audio CD again until I restarted Kodi.
If I change CDs it rips fine without restarting. So I thought Kodi "remembers" in some way which CD was already ripped and which not.
Another note was, that I saw, that different players (Kodi, VLC, Amarok) providing different results of the bitrate. If I rip a CD as a MP3 with "Extreme" settings Kodi says that it is 258kb/s, Amarok says the same....VLC says it is 128 kb/s...
So I don't know which one is lying
...maybe someone else does
Here is a logfile while trying to rip a CD twice:
http://paste.ubuntu.com/10562811/
mediainfo of the result file would be more useful I think.
Edit: Btw. please fix your lirc mess ...
Okay...so Mediainfo shows the same as kodi.log and Amarok. So I presume, because it's VBR with 'extreme' settings, VLC shows a kind of 'minimum bitrate'.
As we talked about that already in IRC, the "can't rip a CD twice without restarting"-question isn't cleared for now. Maybe someone else has an idea why this is the case?!
Bump
Is it better to open a ticket at the bugtracker?
Kodi shouldn´t care on how many times I want to rip a CD
I think, that this comes back to the issues I was trying to duplicate test, which is the ripping using audio decoders and test all settings, because they fail most of them to work or even rip on my tests.
However you will find a temp folder (where your debug logs are) filled with temp files for these rips/fails whatever and they dont get cleared at all, I bet if you delete these files without restarting kodi try see if you can rerip same cd again, I supsect you will be able to.
I can confirm re-ripping same cd is no go. will give this a once over.
I found a couple problems here testing.
1) Indeed the re-ripping same tracks / CD problem is present Ive tried changing encoders and keeping same encoder thers no difference in behaviour however you cant reproduce this reliably enough imo but it is there.
2) Ripping CD via audioencoder.wav you get a file extension sometrack.wav but the codec ID is something like
pcm_s16le and you
get no audio flag on osd where you expect to see
this flag?
The track has a
.wav extension but codec info is
pcm_s16le
Actualy after some testing this looks like possibly a playback issue, tracks ripped outside kodi of the wav familly even though 24bit so pcm_24le intead of 16bit pcm_16le also have no flags, so unless theres a ffmpeg fix the faster correction is to rename the flags I think.
Solution to issue 2) above
https://github.com/xbmc/xbmc/pull/6823
That PR resolves 3 scenarios.
Playing CD directly - pcm stream > no flag
Playing a track ripped with audioencoder.wav - pcm_s16le stream > no flag
Playing a tracked ripped with external wav ripper with 24bit settings - pcm_s24le > no flag
So the main issue related to audio encoders now is ripping same cd repeatedly or sma etrack over and over with same or different encoders will most times need to eject cd or restart kodi, which shouldn't happen really.
Re the bitrate issue: Ive noticed that various encoder addons, dont seem to output the bitrate set in the relevant addon settings, some have large discrepancies between settings and the end result.
It seems some encoders where VBR is applied they have a minimum and maximum bitrate which usually can be adjusted. These encoders though are very basic and dont allow or maybe dont support all the finer adjustments which user like myself would prefer to have.
However pending more testing, I think there are some issues with the values being output vs expected result and this is what prompted me to ask david1977 to test these encoders with varied settings so would have some peer review and results to compare to which this thread should cover also imo.